Memory access control system and mangement method using access control ticket

ABSTRACT

To provide a memory access control system in which partitions, which are divided memory areas generated in a device, can be independently managed. In response to access to the divided memory areas, which are a plurality of partitions, various types of access control tickets are issued under the management of each device or partition manager, and processing based on rules indicated in each ticket is performed in a memory-loaded device. A memory has a partition, which serves as a memory area managed by the partition manager, and a device manager management area managed by the device manager. Accordingly, partition authentication and device authentication can be executed according to either a public-key designation method or a common-key designation method.

TECHNICAL FIELD

[0001] The present invention generally relates to a memory accesscontrol system, a device management apparatus, a partition managementapparatus, a memory-loaded device, a memory access control method, and aprogram storage medium. More particularly, the invention relates to amemory access control system, a device management apparatus, a partitionmanagement apparatus, a memory-loaded device, a memory access controlmethod, and a program storage medium, in which a single memory isdivided into a plurality of areas (partitions), and data managed by aservice provider or a related entity is stored in each partition, so asto allow a user to provide various services by using a singlememory-loaded device.

BACKGROUND ART

[0002] Hitherto, as devices containing a memory, tape media, floppydisks, hard disks, optical discs, semiconductor media, and so on, areutilized. Among these devices, semiconductor media are receivingattention since built-in memories can be securely managed. The reasonfor this is that, in a semiconductor memory, it is easy to implement atamper-resistant structure, and more specifically, a structure in whichaccess is not easily made from an external source.

[0003] The tamper-resistant structure can be implemented, for example,as follows. A device is formed by a single semiconductor chip, and acontrol unit, a memory controller, a non-volatile memory, voltagedetection means, frequency detection means, etc., are provided for thesemiconductor chip. Then, the non-volatile memory is sandwiched by dummylayers, such as alumina layers, so that it cannot be easily read orwritten from or into an external source.

[0004] A known memory structure of such a secure device is describedbelow with reference to the “known memory structure” shown in FIG. 96.The memory shown in FIG. 96 has a configuration which can be used as,for example, e-money. As shown in FIG. 96, the memory area is largelydivided into three areas, i.e., a data area, a memory management area,and a system area.

[0005] In the data area, data based on the “data structure” stored inthe head of each item of data is stored. In this example, data items,such as the user name, the user address, the user telephone number, thebilling, the memo, and the log, are stored. In the memory managementarea, the storage address, the access method, the access authenticationkey, and so on, for accessing each data item in the data area arestored. For example, access can be made to data 1 (user name) in thedata area by read only (Read) with the access authentication key (0123 .. . ). In the system area, a device identifier (ID), and a memorymanagement key, which is an authentication key for reserving the memoryarea in the data area, etc., are stored.

[0006] The data area of the memory device shown in FIG. 96 can bedivided into a plurality of areas, and such divided areas can be managedby different service entities, for example, if e-money services areprovided, by different e-money service providing entities (ex. differentbanks). Data in each divided area is read and written (ex. updating ofbalance data) not only by the individual service providing entities, butalso by users, for example, by a reader/writer (dedicated reader/writeror a PC), which serves as a device access machine installed in a storethat conducts sales using e-money.

[0007] The relationship between the manager and the user of a securedevice having a plurality of divided data areas, such as that shown inFIG. 96, is indicated by the “memory manager/user” in FIG. 97. FIG. 97illustrates a memory manager, which is the entity for issuing the securedevice, and data users, to which the memory areas are assigned from thememory manager, and which utilize the assigned memory areas. As thememory users, a data 1 user through a data 6 user are shown. The memoryusers are banks or stores if e-money services are provided as in theabove-described example.

[0008] The memory manager has an access-control memory management keyfor reserving memory areas, and assigns the memory areas (divided dataareas) to the memory users by using the memory management key. Thememory user has an access authentication key for accessing data in eachdata area, and is able to access the memory in the assigned data area byusing the access authentication key. There are various access modes,such as read, write, and decrement, and the access authentication keysare individually set according to the processing mode, so that adetermination can be individually made as to whether the processing isto be allowed.

[0009] Data 4 in the memory shown in FIG. 96, for example, is billingdata, and the data 4 user is able to perform, as shown in FIG. 97,decrement processing and read/write processing on data 4. As shown inthe table at the bottom right side of FIG. 96, different access keys areassigned to the decrement processing and the read/write processing fordata 4, and it is necessary to access data 4 by using the appropriateaccess key for each processing.

[0010]FIG. 98 illustrates memory reserving processing performed by thememory manager for assigning the data areas in a memory device to thememory users. As shown in the “memory reserving system” shown in FIG.98, the memory manager executes the data-area reserving processing forthe memory device indicated at the right side of FIG. 98 by using amemory-reserving reader/writer (R/W: Reader/Writer) indicated at theleft side of FIG. 98. The memory-reserving reader/writer (R/W:Reader/Writer) is provided with a secure NVRAM (Non-Volatile RAM) forreserving a memory management key. The memory-reserving R/W may be asecure-device-dedicated reader/writer R/W, or if the secure device is adevice provided with an I/F, such as a USB or PCMCIA, thememory-reserving R/W may be a unit which can read and write via such aninterface, for example, a PC.

[0011] For reserving a memory by using the R/W, a device ID is firstread from the secure device. Then, in the R/W, an authentication key iscreated by using the memory management key and the device ID, andperforms mutual authentication with the secure device by using thecreated authentication key. The mutual authentication processing may beperformed by, for example, a common key cryptosystem (ex.ISO/IEC9798-2).

[0012] After successfully performing the mutual authentication, the R/Wencrypts the data structure, the data size, the access method, and theaccess authentication key by using a session key, adds a data-checkingMAC (Message Authentication Code) value if necessary, and sends thecommand to the secure device. Upon receiving the command, the securedevice decrypts the received data and checks the integrity of the dataaccording to the MAC checking processing if necessary. The secure devicethen reserves a memory area in the data area of the memory according tothe data size indicated in the received data, writes the data structureinto the reserved area, and writes the memory address, the accessmethod, and the access authentication key into the memory managementarea.

[0013] In this manner, a plurality of divided data areas are set in thememory device. A description is now given of a memory access method foraccessing the memory device provided with a plurality of divided dataareas according to the “memory access method” shown in FIG. 99. Thereader/writer shown at the left side of FIG. 99 is a memory-accessreader/writer (R/W) possessed by the memory user, which is formed of adedicated R/W or a PC, as in the above-described memory-reserving R/W.The memory-access reader/writer is provided with a secure NVRAM forholding access authentication keys. For accessing a data area of thesecure device by using the R/W, the device ID is first read from thesecure device. Then, in the R/W, an authentication key is created byusing the access authentication key and the device ID, and performsmutual authentication with the secure device by using the createdauthentication key. After successfully performing the mutualauthentication, the R/W makes a predetermined access to the data in thedata area corresponding to the access authentication key.

[0014] In this case, the access method is defined in the memorymanagement area. Accordingly, if, for example, the access authenticationfor decrementing the data in data 4 (billing data) has succeeded, thedata in data 4 can be decremented, but it cannot be incremented oroverwritten as desired, as indicated in the “memory access method” inFIG. 99. In this manner, by setting different access authentication keysused for authentication processing according to the access modes, thesecurity of the individual data items can be enhanced. For example, evenif a decrementing R/W is stolen and the data in the NVRAM in the stolendecrementing R/W is decrypted, the possibility of illegally performingincrementing processing of data 4 (billing data) in the secure device inFIG. 99 is small.

[0015] Generally, the security of money depositing terminals can beimproved, as in ATMs. However, money withdrawing terminals are oftenused as money collecting machines in stores when goods are delivered,and are installed in different places. They are thus highly vulnerableto theft, and it is difficult to improve the security of the moneywithdrawing terminals. Thus, it is effective in setting differentauthentication keys according to the type of data access.

[0016] According to the usage mode for the above-described known memorydevice provided with a plurality of divided data areas, the reservingprocessing for the data area of the memory is performed by executing theauthentication processing using the memory management key, and theaccess processing in each data area is performed by executing theauthentication processing using the-access authentication key. Morespecifically, however, a common key using, for example, DES encryptionalgorithms, is used for the above-described processings, andauthentication using a public key cryptosystem or verification using apublic key cryptosystem is not considered in the above-describedconfiguration.

[0017] In the configuration in which a common key is used for a memorymanagement key and an access authentication key, as described above,authentication and access permission can be advantageously performed bythe single processing. However, if a leakage of the authentication keyoccurs, memory access can be made by using the leaked authenticationkey. Such a configuration is thus problematic in terms of the security.

[0018] In order to decrease the cost of the reader/writer (R/W) foraccessing the memory device, a configuration in which encryptionalgorithms are not loaded in the reader/writer (R/W) can be considered.In such a configuration, however, it is impossible to performauthentication processing with the device and encryption processing forencrypting communication data. Thus, such a configuration is notappropriate for a reader/writer which communicates with a device storinguser billing data and other private information.

DISCLOSURE OF INVENTION

[0019] The present invention has been made in view of theabove-described background of the related art. It is an object of thepresent invention to implement a configuration in which various types ofaccess control tickets are issued in response to access to a memoryhaving a plurality of divided partitions under the control of eachdevice or partition management entity, and processing based on the rulesdescribed in each ticket is executed by a memory-loaded device, therebyimplementing a configuration in which data in each partition isindependently managed.

[0020] It is another object of the present invention to provide a memoryaccess control system, a device management apparatus, a partitionmanagement apparatus, a memory-loaded device, a memory access controlmethod, and a program storage medium in which partition authenticationand device authentication can be executed according to a public keydesignation method or a common key designation method so as to enablethe execution of secure data communication under various environments.

[0021] A first aspect of the present invention is a memory accesscontrol system for a memory-loaded device having a memory in which adata file is stored.

[0022] The memory of the memory-loaded device includes one or morepartitions for storing the data file therein, which serve as memoryareas managed by a partition manager, and a device manager managementarea managed by a device manager, which serves as a manager of thememory-loaded device.

[0023] The memory-loaded device receives from an access unit an accesscontrol ticket managed by the device manager or an access control ticketmanaged by the partition manager as an access control ticket for thememory, and performs processing according to a description of thereceived ticket.

[0024] According to an embodiment of the memory access control system ofthe present invention, the access control ticket includes mutualauthentication designation data that designates a mutual authenticationmode to be executed between the memory-loaded device and the access unitwhich outputs the ticket, and the memory-loaded device executes mutualauthentication according to the mutual authentication designation dataof the access control ticket, and performs processing according to adescription recorded in the received ticket on the condition thatauthentication is successfully conducted.

[0025] According to an embodiment of the memory access control system ofthe present invention, the access control ticket includes ticketverification designation data that designates a verification mode of theaccess control ticket received by the memory-loaded device, and thememory-loaded device executes ticket verification processing accordingto the ticket verification designation data of the access controlticket, and performs processing according to a description recorded inthe received ticket on the condition that verification is successfullyconducted.

[0026] According to an embodiment of the memory access control system ofthe present invention, the access control ticket includes a category oran identifier of issuing means of the access control ticket, and thememory-loaded device executes processing to check whether the ticket isa ticket issued by authorized issuing means based on the category or theidentifier of the issuing means of the access control ticket indicatedin the access control ticket received from the access unit, and performsprocessing according to a description recorded in the received ticket onthe condition that the checking processing is successfully performed.

[0027] According to an embodiment of the memory access control system ofthe present invention, the access control ticket includes a category oran identifier of the access unit, which serves as using means of theaccess control ticket, and the memory-loaded device performs processingto check whether the ticket is a ticket provided by authorized usingmeans based on the category or the identifier of the access unit, whichserves as the using means of the access control ticket, indicated in theaccess control ticket received from the access unit, and performsprocessing according to a description recorded in the received ticket onthe condition that the checking processing is successfully performed.

[0028] According to an embodiment of the memory access control system ofthe present invention, the access control ticket managed by the devicemanager includes a partition registration ticket (PRT) that allowspartition creation processing or partition deletion processing for thememory of the memory-loaded device. When receiving the partitionregistration ticket (PRT) from the access unit, the memory-loaded deviceperforms the partition creation processing or the partition deletionprocessing according to a description recorded in the received partitionregistration ticket (PRT).

[0029] According to an embodiment of the memory access control system ofthe present invention, the partition registration ticket (PRT) is issuedfrom ticket issuing means managed by the device manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0030] According to an embodiment of the memory access control system ofthe present invention, the access control ticket managed by thepartition manager includes a file registration ticket (FRT) that allowsdata-file creation processing or data-file deletion processing in apartition which is generated in the memory of the memory-loaded device.When receiving the file registration ticket (FRT) from the access unit,the memory-loaded device performs the file creation processing or thefile deletion processing according to a description recorded in thereceived file registration ticket (FRT).

[0031] According to an embodiment of the memory access control system ofthe present invention, the file registration ticket (FRT) is issued fromticket issuing means managed by the partition manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0032] According to an embodiment of the memory access control system ofthe present invention, the access control ticket managed by thepartition manager includes a service permission ticket (SPT) that allowsaccess to the data file in a partition in the memory of thememory-loaded device. When receiving the service permission ticket (SPT)from the access unit, the memory-loaded device accesses the data fileaccording to a description recorded in the received service permissionticket (SPT).

[0033] According to an embodiment of the memory access control system ofthe present invention, the service permission ticket (SPT) is issuedfrom ticket issuing means managed by the partition manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0034] According to an embodiment of the memory access control system ofthe present invention, the access control ticket managed by the devicemanager or the partition manager includes a data update ticket (DUT)that allows data stored in the memory of the memory-loaded device to beupdated. When receiving the data update ticket (DUT) from the accessunit, the memory-loaded device performs data updating processingaccording to a description recorded in the received data update ticket(DUT).

[0035] According to an embodiment of the memory access control system ofthe present invention, the data update ticket (DUT) for updating data inthe device manager management area managed by the device manager isissued from ticket issuing means managed by the device manager to theaccess unit, which serves as a ticket user managed by the devicemanager, and the data update ticket (DUT) for updating the data in thepartition managed by the partition manager is issued from ticket issuingmeans managed by the partition manager to the access unit, which servesas a ticket user managed by the partition manager.

[0036] A second aspect of the present invention is a device managementapparatus for executing device management of a memory-loaded device, thememory-loaded device including one or more partitions for storing a datafile therein, which serve as memory areas managed by a partitionmanagement apparatus, and a device manager management area managed bythe device management apparatus.

[0037] The device management apparatus includes issuing means for apartition registration ticket (PRT) as a memory access control ticketthat allows partition creation processing or partition deletionprocessing for a memory of the memory-loaded device.

[0038] According to an embodiment of the device management apparatus ofthe present invention, the device management apparatus includes aregistration authority structure which manages the issuing of a publickey certificate to the memory-loaded device.

[0039] According to an embodiment of the device management apparatus ofthe present invention, the partition registration ticket (PRT) includesmutual authentication designation data that designates a mutualauthentication mode to be executed between the memory-loaded device andan access unit which outputs the ticket.

[0040] According to an embodiment of the device management apparatus ofthe present invention, the partition registration ticket (PRT) includesticket verification designation data that designates a verification modeof the access control ticket received by the memory-loaded device.

[0041] According to an embodiment of the device management apparatus ofthe present invention, the partition registration ticket (PRT) includesa category or an identifier of the issuing means of the access controlticket.

[0042] According to an embodiment of the device management apparatus ofthe present invention, the partition registration ticket (PRT) includesa category or an identifier of an access unit, which serves as usingmeans of the access control ticket.

[0043] A third aspect of the present invention is a partition managementapparatus for executing partition management of a memory-loaded device,the memory-loaded device including one or more partitions for storing adata file therein, which serve as memory areas managed by the partitionmanagement apparatus, and a device manager management area managed by adevice management apparatus.

[0044] The partition management apparatus includes issuing means for anaccess control ticket that allows access to a partition generated in amemory of the memory-loaded device.

[0045] According to an embodiment of the partition management apparatusof the present invention, the access control ticket is a fileregistration ticket (FRT) that allows data-file creation processing ordata-file deletion processing in a partition generated in the memory ofthe memory-loaded device.

[0046] According to an embodiment of the partition management apparatusof the present invention, the access control ticket is a servicepermission ticket (SPT) that allows access to the data file in apartition in the memory of the memory-loaded device.

[0047] According to an embodiment of the partition management apparatusof the present invention, the partition management apparatus includes aregistration authority structure which manages the issuing of a publickey certificate to the memory-loaded device.

[0048] According to an embodiment of the partition management apparatusof the present invention, the access control ticket includes mutualauthentication designation data that designates a mutual authenticationmode to be executed between the memory-loaded device and an access unitwhich outputs the ticket.

[0049] According to an embodiment of the partition management apparatusof the present invention, the access control ticket includes ticketverification designation data that designates a verification mode of theaccess control ticket received by the memory-loaded device.

[0050] According to an embodiment of the partition management apparatusof the present invention, the access control ticket includes a categoryor an identifier of the issuing means of the access control ticket.

[0051] According to an embodiment of the partition management apparatusof the present invention, the access control ticket includes a categoryor an identifier of an access unit, which serves as using means of theaccess control ticket.

[0052] A fourth aspect of the present invention is a memory-loadeddevice having a memory in which data can be stored.

[0053] The memory of the memory-loaded device includes one or morepartitions, which serve as memory areas managed by a partition manager,and a device manager management area managed by a device manager, whichserves as a manager of the memory-loaded device.

[0054] The memory-loaded device includes control means for receivingfrom an access unit an access control ticket managed by the devicemanager or an access control ticket managed by the partition manager asan access control ticket for the memory, and for performing processingaccording to a description of the received ticket.

[0055] According to an embodiment of the memory-loaded device of thepresent invention, the access control ticket includes mutualauthentication designation data that designates a mutual authenticationmode to be executed between the memory-loaded device and the access unitwhich outputs the ticket, and the control means executes mutualauthentication according to the mutual authentication designation dataof the access control ticket, and performs processing according to adescription recorded in the received ticket on the condition thatauthentication is successfully conducted.

[0056] According to an embodiment of the memory-loaded device of thepresent invention, the access control ticket includes ticketverification designation data that designates a verification mode of theaccess control ticket received by the memory-loaded device, and thecontrol means executes ticket verification processing according to theticket verification designation data of the access control ticket, andperforms processing according to a description recorded in the receivedticket on the condition that verification is successfully conducted.

[0057] According to an embodiment of the memory-loaded device of thepresent invention, the access control ticket includes a category or anidentifier of issuing means of the access control ticket, and thecontrol means executes processing to check whether the ticket is aticket issued by authorized issuing means based on the category or theidentifier of the issuing means of the access control ticket indicatedin the access control ticket received from the access unit, and performsprocessing according to a description recorded in the received ticket onthe condition that the checking processing is successfully performed.

[0058] According to an embodiment of the memory-loaded device of thepresent invention, the access control ticket includes a category or anidentifier of the access unit, which serves as using means of the accesscontrol ticket, and the control means performs processing to checkwhether the ticket is a ticket provided by authorized using means basedon the category or the identifier of the access unit, which serves asthe using means of the access control ticket, indicated in the accesscontrol ticket received from the access unit, and performs processingaccording to a description recorded in the received ticket on thecondition that the checking processing is successfully performed.

[0059] A fifth aspect of the present invention is a memory accesscontrol method for a memory-loaded device having a memory in which adata file is stored.

[0060] The memory of the memory-loaded device includes one or morepartitions for storing the data file therein, which serve as memoryareas managed by a partition manager, and a device manager managementarea managed by a device manager, which serves as a manager of thememory-loaded device.

[0061] The memory-loaded device receives from an access unit an accesscontrol ticket managed by the device manager or an access control ticketmanaged by the partition manager as an access control ticket for thememory, and performs processing according to a description of thereceived ticket.

[0062] According to an embodiment of the memory access control method ofthe present invention, the access control ticket includes mutualauthentication designation data that designates a mutual authenticationmode to be executed between the memory-loaded device and the access unitwhich outputs the ticket, and the memory-loaded device executes mutualauthentication according to the mutual authentication designation dataof the access control ticket, and performs processing according to adescription recorded in the received ticket on the condition thatauthentication is successfully conducted.

[0063] According to an embodiment of the memory access control method ofthe present invention, the access control ticket includes ticketverification designation data that designates a verification mode of theaccess control ticket received by the memory-loaded device, and thememory-loaded device executes ticket verification processing accordingto the ticket verification designation data of the access controlticket, and performs processing according to a description recorded inthe received ticket on the condition that verification is successfullyconducted.

[0064] According to an embodiment of the memory access control method ofthe present invention, the access control ticket includes a category oran identifier of issuing means of the access control ticket, and thememory-loaded device executes processing to check whether the ticket isa ticket issued by authorized issuing means based on the category or theidentifier of the issuing means of the access control ticket indicatedin the access control ticket received from the access unit, and performsprocessing according to a description recorded in the received ticket onthe condition that the checking processing is successfully performed.

[0065] According to an embodiment of the memory access control method ofthe present invention, the access control ticket includes a category oran identifier of the access unit, which serves as using means of theaccess control ticket, and the memory-loaded device performs processingto check whether the ticket is a ticket provided by authorized usingmeans based on the category or the identifier of the access unit, whichserves as the using means of the access control ticket, indicated in theaccess control ticket received from the access unit, and performsprocessing according to a description recorded in the received ticket onthe condition that the checking processing is successfully performed.

[0066] According to an embodiment of the memory access control method ofthe present invention, the access control ticket managed by the devicemanager includes a partition registration ticket (PRT) that allowspartition creation processing or partition deletion processing for thememory of the memory-loaded device. When receiving the partitionregistration ticket (PRT) from the access unit, the memory-loaded deviceperforms the partition creation processing or the partition deletionprocessing according to a description recorded in the received partitionregistration ticket (PRT).

[0067] According to an embodiment of the memory access control method ofthe present invention, the partition registration ticket (PRT) is issuedfrom ticket issuing means managed by the device manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0068] According to an embodiment of the memory access control method ofthe present invention, the access control ticket managed by thepartition manager includes a file registration ticket (FRT) that allowsdata-file creation processing or data-file deletion processing in apartition which is generated in the memory of the memory-loaded device.When receiving the file registration ticket (FRT) from the access unit,the memory-loaded device performs the file creation processing or thefile deletion processing according to a description recorded in thereceived file registration ticket (FRT).

[0069] According to an embodiment of the memory access control method ofthe present invention, the file registration ticket (FRT) is issued fromticket issuing means managed by the partition manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0070] According to an embodiment of the memory access control method ofthe present invention, the access control ticket managed by thepartition manager includes a service permission ticket (SPT) that allowsaccess to the data file in a partition in the memory of thememory-loaded device. When receiving the service permission ticket (SPT)from the access unit, the memory-loaded device accesses the data fileaccording to a description recorded in the received service permissionticket (SPT).

[0071] According to an embodiment of the memory access control method ofthe present invention, the service permission ticket (SPT) is issuedfrom ticket issuing means managed by the partition manager to the accessunit, which serves as a ticket user managed by the partition manager.

[0072] According to an embodiment of the memory access control method ofthe present invention, the access control ticket managed by the devicemanager or the partition manager includes a data update ticket (DUT)that allows data stored in the memory of the memory-loaded device to beupdated. When receiving the data update ticket (DUT) from the accessunit, the memory-loaded device performs data updating processingaccording to a description recorded in the received data update ticket(DUT).

[0073] According to an embodiment of the memory access control method ofthe present invention, the data update ticket (DUT) for updating data inthe device manager management area managed by the device manager isissued from ticket issuing means managed by the device manager to theaccess unit, which serves as a ticket user managed by the devicemanager, and the data update ticket (DUT) for updating the data in thepartition managed by the partition manager is issued from ticket issuingmeans managed by the partition manager to the access unit, which servesas a ticket user managed by the partition manager.

[0074] A sixth aspect of the present invention is a program storagemedium for providing a computer program for executing memory accesscontrol processing on a computer system, the memory access controlprocessing being performed for a memory-loaded device having a memory,the memory including one or more partitions for storing a data filetherein, which serve as memory areas managed by a partition manager, anda device manager management area managed by a device manager, whichserves as a manager of the memory-loaded device. The computer programincludes a step of receiving from an access unit an access controlticket managed by the device manager or an access control ticket managedby the partition manager as an access control ticket for the memory, astep of executing mutual authentication with the access unit, a step ofexecuting ticket verification processing according to a description ofthe received ticket, and a step of performing processing according tothe description of the received ticket.

[0075] The program storage medium of the present invention is a mediumfor providing a computer program to, for example, a general-purposecomputer system that is able to execute various program codes, in acomputer-readable format. The form of the medium is not particularlyrestricted, and may be a recording medium, such as CD, FD, or MO, or acommunication medium.

[0076] In such a program storage medium, the cooperative relationshipbetween the computer program and the storage medium in terms of thestructure or the function, which is to implement the functions of thepredetermined computer program on the computer system, is defined. Inother words, by installing the computer program into the computer systemvia the storage medium, the cooperative functions can be exhibited onthe computer system, thereby obtaining operations and advantages similarto those of the other aspects of the present invention.

[0077] Further objects, features and advantages of the present inventionwill become apparent from the following description of the embodimentsand the attached drawings. In this specification, the system means alogical group of a plurality of devices, and it is not essential thatthe devices having individual configurations be located in the samecasing.

BRIEF DESCRIPTION OF THE DRAWINGS

[0078]FIG. 1 is a first schematic diagram illustrating an overview of asystem configuration of the present invention.

[0079]FIG. 2 is a second schematic diagram illustrating an overview ofthe system configuration of the present invention.

[0080]FIG. 3 is a third schematic diagram illustrating an overview ofthe system configuration of the present invention.

[0081]FIG. 4 is a diagram illustrating the relationship between accesscontrol ticket issuing means and using means in the system of thepresent invention.

[0082]FIG. 5 is a diagram illustrating the configuration provided of adevice with a memory in the system of the present invention.

[0083]FIG. 6 is a diagram illustrating the memory format of the deviceof the present invention.

[0084]FIG. 7 is a diagram illustrating the configuration of a devicemanager in the system of the present invention.

[0085]FIG. 8 is a diagram illustrating the configuration ofdevice-manager control means in the system of the present invention.

[0086]FIG. 9 is a diagram illustrating the configuration of a partitionmanager in the system of the present invention.

[0087]FIG. 10 is a diagram illustrating the configuration of areader/writer (R/W) in the system of the present invention.

[0088]FIG. 11 is a diagram illustrating a format of a public keycertificate that can be used in the system of the present invention.

[0089]FIG. 12 is a flowchart illustrating a signature generationprocessing according to a public key system that can be used in thesystem of the present invention.

[0090]FIG. 13 is a flowchart illustrating signature verificationprocessing according to a public key system that can be used in thesystem of the present invention.

[0091]FIG. 14 is a diagram illustrating the data configuration of amanufacture information block of the data stored in the memory of thedevice of the present invention.

[0092]FIG. 15 is a diagram illustrating the data configuration of adevice management information block of the data stored in the memory ofthe device of the present invention.

[0093]FIG. 16 is a diagram illustrating the data configuration of apublic-key device key definition block of the data stored in the memoryof the device of the present invention.

[0094]FIG. 17 is a diagram illustrating the data configuration of acommon-key device key definition block of the data stored in the memoryof the device of the present invention.

[0095]FIG. 18 is a diagram illustrating the data configuration of adevice key area of the data stored in the memory of the device of thepresent invention.

[0096]FIG. 19 is a diagram illustrating the data configuration of apartition definition block of the data stored in the memory of thedevice of the present invention.

[0097]FIG. 20 is a diagram illustrating the data configuration of apartition management information block of the data stored in the memoryof the device of the present invention.

[0098]FIG. 21 is a diagram illustrating the data configuration of apublic-key partition key definition block of the data stored in thememory of the device of the present invention.

[0099]FIG. 22 is a diagram illustrating the data configuration of acommon-key partition key definition block of the data stored in thememory of the device of the present invention.

[0100]FIG. 23 is a diagram illustrating the data configuration of apartition key area of the data stored in the memory of the device of thepresent invention.

[0101]FIG. 24 is a diagram illustrating the data configuration of a filedefinition block of the data stored in the memory of the device of thepresent invention.

[0102]FIG. 25 is a diagram illustrating the type of file structure ofthe data stored in the memory of the device of the present invention.

[0103]FIG. 26 is a diagram illustrating the format of a partitionregistration ticket (PRT) as an access control ticket applied in thesystem of the present invention.

[0104]FIG. 27 is a diagram illustrating the format of a fileregistration ticket (FRT) as an access control ticket applied in thesystem of the present invention.

[0105]FIG. 28 is a diagram illustrating the format (first example) of aservice permission ticket (SPT) as an access control ticket applied inthe system of the present invention.

[0106]FIG. 29 is a diagram illustrating the type of file access modeusing a service permission ticket (SPT) as an access control ticketapplied in the system of the present invention.

[0107]FIG. 30 is a diagram illustrating the file structure to beaccessed using a service permission ticket (SPT) as an access controlticket applied in the system of the present invention.

[0108]FIG. 31 is a diagram illustrating the format (second example) of aservice permission ticket (SPT) as an access control ticket applied inthe system of the present invention.

[0109]FIG. 32 is a diagram illustrating the format of a data updateticket (DUT) as an access control ticket applied in the system of thepresent invention.

[0110]FIG. 33 is a diagram illustrating the data to be updated using adata update ticket (DUT) as an access control ticket applied in thesystem of the present invention.

[0111]FIG. 34 is a diagram illustrating an overview of the processinguntil the use of the device in the system of the present invention.

[0112]FIG. 35 is a flowchart illustrating device initial registrationprocessing performed by a device manufacturing entity in the system ofthe present invention.

[0113]FIG. 36 is a first flowchart illustrating device initialregistration processing performed by a device manager in the system ofthe present invention.

[0114]FIG. 37 is a second flowchart illustrating device initialregistration processing performed by the device manager in the system ofthe present invention.

[0115]FIG. 38 is a third flowchart illustrating device initialregistration processing performed by the device manager in the system ofthe present invention.

[0116]FIG. 39 is a fourth flowchart illustrating device initialregistration processing performed by the device manager in the system ofthe present invention.

[0117]FIG. 40 is a fifth flowchart illustrating device initialregistration processing performed by the device manager in the system ofthe present invention.

[0118]FIG. 41 is a diagram illustrating data stored in the device afterthe device initial registration processing is performed by the devicemanager in the system of the present invention.

[0119]FIG. 42 is a first flowchart illustrating public key certificateissuing processing performed by the device manager in the system of thepresent invention.

[0120]FIG. 43 is a second flowchart illustrating public key certificateissuing processing performed by the device manager in the system of thepresent invention.

[0121]FIG. 44 is a flowchart illustrating public key certificate issuingprocessing performed by the device manager in the system of the presentinvention.

[0122]FIG. 45 is a flowchart illustrating public key certificate issuingprocessing performed by the device manager in the system of the presentinvention.

[0123]FIG. 46 is a diagram illustrating data stored in the device afterpublic key certificate issuing processing is performed by the devicemanager in the system of the present invention.

[0124]FIG. 47 is a flowchart illustrating partition creation/deletionprocessing for the device in the system of the present invention.

[0125]FIG. 48 is a first flowchart illustrating mutual authenticationprocessing with the device in the system of the present invention.

[0126]FIG. 49 is a second flowchart illustrating mutual authenticationprocessing (device authentication) with the device in the system of thepresent invention.

[0127]FIG. 50 is a diagram illustrating mutual authentication processingaccording to a public key system with the device in the system of thepresent invention.

[0128]FIG. 51 is a diagram illustrating the configuration of anauthentication table generated in the device after mutual authenticationprocessing with the device is performed in the system of the presentinvention.

[0129]FIG. 52 is a diagram illustrating the configuration of anauthentication table generated in the reader/writer after mutualauthentication processing with the device is performed in the system ofthe present invention.

[0130]FIG. 53 is a diagram illustrating mutual authentication processingaccording to a common key system with the device in the system of thepresent invention.

[0131]FIG. 54 is a diagram illustrating mutual authentication processingaccording to a common key system with the device in the system of thepresent invention.

[0132]FIG. 55 is a third flowchart illustrating mutual authenticationprocessing (partition authentication) with the device in the system ofthe present invention.

[0133]FIG. 56 is a fourth flowchart illustrating mutual authenticationprocessing (partition authentication) with the device in the system ofthe present invention.

[0134]FIG. 57 is a first flowchart illustrating ticket integrity/userchecking in the system of the present invention.

[0135]FIG. 58 is a second flowchart illustrating ticket integrity/userchecking in the system of the present invention.

[0136]FIG. 59 is a first flow illustrating a method for creating a MACthat can be used for the integrity of the ticket in the system of thepresent invention.

[0137]FIG. 60 is a first flowchart illustrating a partitioncreation/deletion operation in the system of the present invention.

[0138]FIG. 61 is a second flowchart illustrating the partitioncreation/deletion operation in the system of the present invention.

[0139]FIG. 62 is a first flowchart illustrating partition initialregistration processing in the system of the present invention.

[0140]FIG. 63 is a second flowchart illustrating partition initialregistration processing in the system of the present invention.

[0141]FIG. 64 is a third flowchart illustrating partition initialregistration processing in the system of the present invention.

[0142]FIG. 65 is a diagram illustrating data stored in the device afterpartition initial registration processing is performed in the system ofthe present invention.

[0143]FIG. 66 is a first flowchart illustrating public key certificateissuing processing performed by a partition manager in the system of thepresent invention.

[0144]FIG. 67 is a second flowchart illustrating public key certificateissuing processing performed by the partition manager in the system ofthe present invention.

[0145]FIG. 68 is a diagram illustrating partition creation processingperformed by the partition manager in the system of the presentinvention when public-key authentication and public-key ticketverification are performed.

[0146]FIG. 69 is a diagram illustrating partition creation processingperformed by the partition manager in the system of the presentinvention when public-key authentication and common-key ticketverification are performed.

[0147]FIG. 70 is a diagram illustrating partition creation processingperformed by the partition manager in the system of the presentinvention when common-key authentication and common-key ticketverification are performed.

[0148]FIG. 71 is a diagram illustrating partition creation processingperformed by the partition manager in the system of the presentinvention when common-key authentication and public-key ticketverification are performed.

[0149]FIG. 72 is a flowchart illustrating file creation/deletionprocessing using a file registration ticket (FRT) in the system of thepresent invention.

[0150]FIG. 73 is a flowchart illustrating file creation/deletionprocessing using a file registration ticket (FRT) in the system of thepresent invention.

[0151]FIG. 74 is a diagram illustrating data stored in the device aftera file is created by using a file registration ticket (FRT) in thesystem of the present invention.

[0152]FIG. 75 is a diagram illustrating file creation processing using afile registration ticket (FRT) in the system of the present inventionwhen public-key authentication and public-key ticket verification areperformed.

[0153]FIG. 76 is a diagram illustrating file creation processing using afile registration ticket (FRT) in the system of the present inventionwhen public-key authentication and common-key ticket verification areperformed.

[0154]FIG. 77 is a diagram illustrating file creation processing using afile registration ticket (FRT) in the system of the present inventionwhen common-key authentication and common-key ticket verification areperformed.

[0155]FIG. 78 is a diagram illustrating file creation processing using afile registration ticket (FRT) in the system of the present inventionwhen common-key authentication and public-key ticket verification areperformed.

[0156]FIG. 79 is a flowchart illustrating file access processing using aservice permission ticket (SPT) in the system of the present invention.

[0157]FIG. 80 is a flowchart illustrating a file open operation using aservice permission ticket (SPT) in the system of the present invention.

[0158]FIG. 81 is a diagram illustrating the configuration (firstexample) of a file open table generated by the file open operation usinga service permission ticket (SPT) in the system of the presentinvention.

[0159]FIG. 82 is a diagram illustrating the configuration (secondexample) of a file open table generated by the file open operation usinga service permission ticket (SPT) in the system of the presentinvention.

[0160]FIG. 83 is a diagram illustrating a first example of file accessprocessing using a service permission ticket (SPT) in the system of thepresent invention.

[0161]FIG. 84 is a diagram illustrating a second example of file accessprocessing using a service permission ticket (SPT) in the system of thepresent invention.

[0162]FIG. 85 is a diagram illustrating the handling of session keysgenerated by performing authentication in the system of the presentinvention.

[0163]FIG. 86 is a flowchart of a first example of file accessprocessing using a service permission ticket (SPT) in the system of thepresent invention.

[0164]FIG. 87 is a flowchart of a second example of file accessprocessing using a service permission ticket (SPT) in the system of thepresent invention.

[0165]FIG. 88 is a diagram illustrating an example of access processingof a composite file using a service permission ticket (SPT) in thesystem of the present invention.

[0166]FIG. 89 is a diagram illustrating file access processing using aservice permission ticket (SPT) in the system of the present inventionwhen public-key authentication and public-key ticket verification areperformed.

[0167]FIG. 90 is a diagram illustrating file access processing using aservice permission ticket (SPT) in the system of the present inventionwhen public-key authentication and common-key ticket verification areperformed.

[0168]FIG. 91 is a diagram illustrating file access processing using aservice permission ticket (SPT) in the system of the present inventionwhen common-key authentication and common-key ticket verification areperformed.

[0169]FIG. 92 is a diagram illustrating file access processing using aservice permission ticket (SPT) in the system of the present inventionwhen common-key authentication and public-key ticket verification areperformed.

[0170]FIG. 93 is a flowchart illustrating data updating processing usinga data update ticket (DUT) in the system of the present invention.

[0171]FIG. 94 is a flowchart illustrating a data updating operationusing a data update ticket (DUT) in the system of the present invention.

[0172]FIG. 95 is a diagram illustrating an example of data updatingprocessing using a data update ticket (DUT) in the system of the presentinvention.

[0173]FIG. 96 is a diagram illustrating a known memory structure.

[0174]FIG. 97 is a diagram illustrating a known relationship between amemory manager and users.

[0175]FIG. 98 is a diagram illustrating known memory area reservingprocessing.

[0176]FIG. 99 is a diagram illustrating a known memory access method.

BEST MODE FOR CARRYING OUT THE INVENTION

[0177] Embodiments of the present invention are described in detailbelow with reference to the drawings.

[0178] A description is given in the following order.

[0179] A. Description of Entity and Ticket Configuration in DataProcessing System Using Device

[0180] A1. Overview of Data Management System Using Memory-Loaded Device

[0181] A2. Device Configuration

[0182] A3. Device Manager Configuration

[0183] A4. Partition Manager Configuration

[0184] A5. Ticket User (Reader/Writer as Device Access Unit)Configuration

[0185] A6. Public Key Certificate

[0186] A7. Storage Data in Device Memory

[0187] A7.1. Device-Unique-Information/Device-Partition-Information Area

[0188] A7.2. Partition Area

[0189] A8. Data Format of Each Ticket

[0190] A8.1. Partition Registration Ticket (PRT)

[0191] A8.2. File Registration Ticket (FRT)

[0192] A8.3. Service Permission Ticket (SPT)

[0193] A8.4. Data Update Ticket (DUT)

[0194] B. Detailed Description of Device Distribution to User, VariousSettings for Device, and Device Usage Processing

[0195] B1. Flow from Device Initial registration to Usage

[0196] B2. Initial Registration processing by Device ManufacturingEntity

[0197] B3. Device Manager Management Processing

[0198] B3.1. Device Registration processing by Device Manager

[0199] B3.2. Public Key Certificate Issuing Processing under DeviceManager Control

[0200] B4. Partition Manager Management Processing

[0201] B4.1. Partition Setting Registering and Deletion Processing UsingPartition Registration Ticket (PRT) under Partition Manager Control

[0202] B4.2. Public Key Certificate Issuing Processing under PartitionManager Control

[0203] B4.3. Processing Procedure in Each Partition Creation ProcessingMethod

[0204] B4.4. File Creation and Deletion Processing Using FileRegistration Ticket (FRT)

[0205] B4.5. Processing Procedure in Each File Creation ProcessingMethod

[0206] B4.6. Service (File Access) Processing Using Service PermissionTicket (SPT)

[0207] B4.7. Processing Procedure in Each Access Processing Method UsingService Permission Ticket (SPT)

[0208] B5. Device Data Updating Processing Using Data Update Ticket(DUT)

[0209] [A1. Overview of Data Management System Using Memory-LoadedDevice]

[0210]FIG. 1 illustrates an overview of a data management systemaccording to the present invention. A memory-loaded device (hereinafterreferred to as the “device”) 100 is manufactured by a devicemanufacturing entity (manufacturer) 500, and is provided to a user underthe management of a device manager (DM) 200, which serves as a devicemanagement entity, and is utilized. The device may be provided to theuser in any mode, such as a loan or a sale (including assignment).

[0211] In the device 100, a memory area is divided into a plurality ofpartitions, which serve as data storage areas, and the individualpartitions (Partitions A, B, . . . Z) are utilized for various servicesunder the management of partition managers, which serve as variousservice entities (A, B, . . . Z) 300A through 300Z.

[0212] For performing partition setting registration processing for thedevice 100, file setting registration processing for the partitions setin the device, and access processing for each registered file, accesscontrol tickets for the device issued by authorized ticket issuing means(Ticket Issuer) are required.

[0213] For the partition setting registration processing for the device100, a partition registration ticket (PRT) issued by authorized ticketissuing means (Ticket Issuer) is required. For the file settingregistration processing for the partitions set in the device, a fileregistration ticket (FRT) issued by the authorized ticket issuing means(Ticket Issuer) is required. For making access to each file, a servicepermission ticket (SPT) issued by authorized ticket issuing means(Ticket Issuer) is required.

[0214] Each ticket stores access rules for the device 100, for example,the rules concerning authentication processing between the device and areader/writer that performs various types of processing, such as readingand writing data from and into the device. The ticket also stores thepartition size that can be set if the ticket is the partitionregistration ticket (PRT), the file size that can be set if the ticketis the file registration ticket (FRT), and the access mode that can beexecuted (ex. data reading and writing) if the ticket is the servicepermission ticket (SPT). Information concerning the ticket issuer andthe ticket user, and other information are also stored. Additionally, atamper-verification ICV (Integrity Check Value) for the data stored inthe ticket is recorded, and only when the data stored in the ticket isnot tampered with, the processing can be executed within the range ofthe permission recorded in the ticket. Details of such tickets arediscussed below.

[0215] In the example shown in FIG. 1, the ticket issuing means (TicketIssuer) for issuing the partition registration ticket (PRT) is set inthe device manager (DM) 200, and the ticket issuing means (TicketIssuer) for issuing the file registration ticket (FRT) and the servicepermission ticket (SPT) are set in the service entity A, 300A, whichserves as the partition manager. In the configuration shown in FIG. 1,basically, service entities B . . . Z, 300B through 300Z have aconfiguration similar to that of the service entity A, and the ticketissuing means (Ticket Issuer) for issuing the file registration ticket(FRT) and the service permission ticket (SPT) is set in each serviceentity.

[0216] In FIG. 1, the service entity and the partition manager (PM) areindicated as the same entity. However, they do not have to be the sameentity. Alternatively, the partition manager for managing the partitionsas memory areas set in the memory may be a different entity from theservice entity that borrows the partitions as the memory areas from thepartition manager under a predetermined contract, stores various filesin the borrowed partitions, and provides services. For the sake ofsimplicity, however, the configuration in which the service entity alsoserves as the partition manager is discussed below.

[0217] The partition manager (PM), which serves as one of the serviceentities 300A through 300Z, requests the device manager (DM) 200 toissue a partition registration ticket (PRT) under a predeterminedcontract by, for example, paying a certain price, and the ticket issuingmeans (Ticket Issuer) in the device manager (DM) receives a permissionfrom the device manager (DM) and issues the partition registrationticket (PRT) for the partition manager (PM), which serves as the serviceentity.

[0218] Each service entity (partition manager (PM)) 300 accesses thedevice 100 owned by the user via a communication interface (I/F) so asto perform authentication processing and verification processingaccording to the rules recorded in the partition registration ticket(PRT) received from the device manager (DM) 200, and also performs thepartition setting registration processing within the range of thepermission recorded in the partition registration ticket (PRT). Thisprocessing is described in detail below.

[0219] The communication I/F may be any type of cable or wirelessinterface through which data communication can be performed with anexternal unit (device). For example, if the device has a USB-connectingconfiguration, the communication I/F may be a USBI/F. If the device isan IC card type, the communication I/F may be an IC-card reader/writer.If the device has various communication functions, such as a publicline, a communication line, or the Internet, or if the device isconnectable to such a communication unit, the communication I/F may be adata communication I/F according to the corresponding communicationsystem.

[0220] After the partitions are set in the device 100 for the serviceentity 300, the service entity 300 accesses the device 100 owned by theuser via the communication interface (I/F) so as to performauthentication processing and verification processing according to therules recorded in the file registration ticket (FRT) issued by theticket issuing means (Ticket Issuer) in the service entity 300, and alsoperforms the file setting registration processing for the file withinthe range of the permission recorded in the file registration ticket(FRT). These processings are described in detail below.

[0221] The service entity 300 also accesses the device 100 owned by theuser via the communication interface (I/F) so as to performauthentication processing and verification processing according to therules recorded in the service permission ticket (SPT) issued by theticket issuing means (Ticket Issuer) in the service entity, and alsoperforms the access processing (ex. data reading and writing) within therange of the permission recorded in the service permission ticket (SPT).These processings are discussed in detail below.

[0222] As shown in FIG. 1, a code management institute 400 is set at alevel higher than the device manager 200 and the partition manager 300,and assigns code, which serve as ID information of the correspondingentity, to each of the device manager and the partition manager. Thecode assigned to each manager is used as storage data in access controltickets, such as the above-described partition registration ticket(PRT), the file registration ticket (FRT), and so on.

[0223] Before the device 100 is provided (ex. loaned or sold) to theuser and is utilized, the device manager (DM) 200 for managing theprovided device is set, and device-manager management information, suchas the device manager code, is written into the provided device. Detailsof such data are described below.

[0224] The relationship between public-key-certificate issuingprocessing and the entities in the data management system using thememory device is described below with reference to FIG. 2.

[0225]FIG. 2 illustrates the device manager as the device managemententity, the two partition managers 300A and 300B as the managemententities for the partitions set in the device, and the code managementinstitute 400 for assigning ID code to the device manager 200.Additionally, there is provided a device-manager certificate authority(CA(DEV)) 610, which, in response to a public-key-certificate issuingrequest from a registration authority 210 managed by the device manager200, issues a device public key certificate (CERT-DEV) corresponding tothe device manager 200, individual units managed by the device manager(partition registration ticket (PRT) issuing means (PRT Issuer) 210, orthe device 100. There are also provided partition-manager certificateauthorities (CA(PAR)) 620 and 630 for issuing a partition public keycertificate (CERT-PAR) corresponding to individual units managed by thepartition managers 300A and 300B (file registration ticket (FRT) issuingmeans (FRT Issuer) 310, service-permission-ticket issuing means (SPTIssuer) 320, reader/writers 711 through 714 as device access units,i.e., ticket users, or a partition of the device 100.

[0226] In the configuration shown in FIG. 2, the device-managercertificate authority: CA for DM (or CA(DEV)) 610 and thepartition-manager certificate authorities: CA for PAR (or CA(PAR)) 620and 630 are separately provided as individual certificate authorities.However, this configuration may be changed as desired. For example, asingle certificate authority having both functions may be provided, or acommon certificate authority for a plurality of partition managers and adevice-manager certificate authority may be separately provided.

[0227] The device manager 200 and the partition managers 300A and 300Bare provided with registration authorities (RA) 220 and 320,respectively. The registration authorities 220 and 320 receive requeststo issue public key certificates, i.e., the public key certificates ofthe device manager 200 and the partition managers 300A and 300B, thepublic key certificates of the individual units (ticket issuing meansand ticket users) managed by the managers, and a public key certificateof the device 100. Then, the registration authorities 220 and 320 checkthe received public-key issuing requests, then transfer the public-keyissuing requests to the certificate authorities, and also manages theissued public key certificates.

[0228] The public key certificates issued by the certificate authorities(CAs) 610, 620, and 630 via the registration authorities (RAs) 220 and320 are stored in the device 100, and are used for the processing to beperformed for the device 100, for example, the partition settingprocessing, the file setting processing for the partitions, the mutualauthentication processing required for accessing the file, or theintegrity verification processing for the above-described tickets.Details of the public-key-certificate issuing processing, and theabove-described processings using the public key certificates arediscussed below.

[0229] In FIG. 2, as the partitions, the device 100 possesses amanagement partition: PM1Area for the partition manager 1, 300A, amanagement partition: PM2Area for the partition manager 2, 300B, and aDMArea as the management area for the device manager 200.

[0230] The device manager 200 possesses thepartition-registration-ticket issuing means (PRT Issuer) 210, and thepartition manager 300 possesses the file-registration-ticket issuingmeans (FRT Issuer) 310 and the service-permission-ticket issuing means(SPT Issuer) 320. The PRT Issuer 210, the FRT Issuer 310, and the SPTIssuer 320 issue the corresponding tickets.

[0231] The partition manager 1, 300A is provided with the reader/writers711 through 713 (data reading and writing interface of the device)dedicated for the individual tickets, i.e., PRT, FRT, and SPT,respectively, while the partition manager 2, 300B has the commonreader/writer 714 for all the tickets. Accordingly, the reader/writermay be configured in various forms.

[0232] A specific example of the entities is described below withreference to FIG. 3. FIG. 3 illustrates an example of the configurationusing the device. In this configuration, as the partition managers,which serve as the service entities for providing services by utilizingthe partitions set in the device, Tozai Railway Co., Ltd., and NanpokuRailway Co., Ltd. are considered. As the device manager for performingthe partition setting registration for the partition managers, NipponRailway Group is considered.

[0233] Tozai Railway Co., Ltd. sets and registers a plurality of files,i.e., a commuter ticket file, a prepaid file, and a file for the others,in the partition: PM1, which is set in the user device and managed byTozai Railway Co., Ltd. The partition manager, which serves as a serviceentity, is able to register various files in partitions which areassigned from the device manager and which are set according to theservices provided by the partition manager. For setting and registeringfiles, the file registration ticket (FRT) is required.

[0234] Tozai Railway Co., Ltd. functions as a partition manager formanaging one of the partitions, i.e., partition: PM1Area. Authenticationprocessing and verification processing are performed according to therules recorded in the partition registration ticket (PRT) issued by thePRT Issuer of Nippon Railway Group, which serves as the device manager,and the partition setting registration processing is performed withinthe range of the permission recorded in the partition registrationticket (PRT). Then, partition: PM1Area is assigned to Tozai Railway Co.,Ltd.

[0235] Tozai Railway Co., Ltd. sets various files, such as a commuterticket file and a prepaid file, in the assigned partition: PM1Areaaccording to the services to be provided by Tozai Railway Co., Ltd. Inthe data storage area in the commuter ticket file, various data requiredas ticket management data, such as the ticket user, the usage period,and the usage zone, can be recorded. In the prepaid file, the user name,the prepaid amount of money, the balance data, etc., are recorded. Inthe file setting processing, authentication processing and verificationprocessing are executed according to the rules recorded in the fileregistration ticket (FRT) issued by the FRT Issuer of Tozai Railway Co.,Ltd., and the file setting registration processing is performed withinthe range of the permission recorded in the file registration ticket(FRT).

[0236] The device in which various files are set as described above isutilized by the user. For example, the user is able to utilize thedevice by setting it in a ticket machine provided with a reader/writer,which serves as a device access unit. For example, the commuter ticketfile is accessed by an authorized reader/writer installed in the ticketmachine so as to read the usage zone. The prepaid file is also accessedto perform updating processing for the balance data in the prepaid file.

[0237] The service permission ticket (SPT) issued by the servicepermission ticket (SPT) issuing means (SPT issuer) of Tozai Railway Co.,Ltd. stores which file to be accessed and which processing (read, write,decrement, etc.) to be executed in the device. The tickets are storedin, for example, a reader/writer, which serves as an authorized deviceaccess unit installed in the ticket machine, and authenticationprocessing with the device and ticket verification processing areperformed according to the rules recorded in the tickets. If both thereader/writer and the device are found to be authorized devices, and ifthe tickets are authorized tickets, the processing (ex. reading,writing, decrementing, etc., of the data in the file) is performedwithin the range of the permission recorded in the service permissionticket (SPT).

[0238]FIG. 4 illustrates a typical relationship between the ticketissuing means (Ticket Issuer) for issuing various tickets, such as thepartition registration ticket (PRT), the file registration ticket (FRT),and the service permission ticket (SPT), and the ticket user (TicketUser) which utilizes the tickets issued by the ticket issuing means.

[0239] As being discussed with reference to, for example, FIG. 1, theticket issuing means (Ticket Issuer) is under the control of the devicemanager or the partition manager, and issues the partition registrationticket (PRT), the file registration ticket (FRT), and the servicepermission ticket (SPT), according to the processing to be performed onthe device. The ticket user (Ticket User) is a machine or means forutilizing the tickets issued by the ticket issuing means, and morespecifically, it serves as a device access unit, for example, areader/writer, for reading and writing data into and from the device.

[0240] As shown in FIG. 4, the ticket user is able to store and utilizea plurality of tickets. Alternatively, the ticket user is able to storeonly a single ticket, for example, only the service permission ticket(SPT) that allows only the reading of the zone data of the commuterticket file discussed with reference to FIG. 3, and then reads only thezone data.

[0241] For example, at a commuter-ticket read only machine of a railwaycompany, which is a certain entity (partition manager), a reader/writer,which serves as a device access unit, storing only the servicepermission ticket (SPT) that allows only the reading of the zone data ofthe commuter ticket file is set. Then, the zone data can be read fromthe device owned by the user. For example, in a reader/writer, whichserves as a device access unit, installed in a ticket machine forperforming processing for commuter tickets and prepaid tickets, theservice permission ticket (SPT) allowing only the reading of the zonedata of the commuter ticket file, and the service permission ticket(SPT) allowing the decrementing processing for the balance data of theprepaid file are stored together. Then, the processing can be executedfor both the files, i.e., the commuter ticket file and for the prepaidfile.

[0242] The ticket user (ex. reader/writer) may be configured such thatthe partition registration ticket (PRT), the file registration ticket(FRT), and the service permission ticket (SPT) are stored, and all thecorresponding processings, such as partition registration, fileregistration, and data access in the file, are executable. In thismanner, the processing executable by the ticket user is determined bythe types of tickets possessed by the ticket user.

[0243] [A2. Device Configuration]

[0244] A description is given below of a device provided with theabove-described memory whose data storage area is divided into aplurality of partitions. FIG. 5 is a schematic diagram of the device.

[0245] As shown in FIG. 5, the device 100 includes: a CPU (CentralProcessing Unit) 101 having a program execution function and acomputation processing function; a communication interface 102 having aninterface function of performing communication processing with externaldevices, such as a reader/writer, which serves as a device access unit;a ROM (Read Only Memory) 103 storing various programs to be executed bythe CPU 101, for example, an encryption processing program; a RAM(Random Access Memory) 104, which serves as a load area for programs tobe executed, or a work area for the various types of program processing;an encryption processor 105 for performing encryption processing, suchas authentication processing with external devices, digital signaturecreation, verification processing, encryption of storage data, anddecoding processing; and a memory 106, which is formed of, for example,an EEPROM (Electrically Erasable Programmable ROM), storing theabove-described partitions and files, and also storing device-uniqueinformation including various key data. Information stored in the memory106 (ex. EEPROM) 106 is discussed below.

[0246] The data storage structure of the memory 106 is shown in FIG. 6.The memory is, for example, a flash memory, which is referred to as anEEPROM (Electrically Erasable Programmable ROM), which is one form of anelectrically erasable non-volatile memory.

[0247] As shown in FIG. 6, in this embodiment, the data storage area hasa number of 0xFFFF blocks, each block having 32 bytes, and as the mainareas, a partition area, an unused area, adevice-unique-information/device-partition-information area areprovided.

[0248] In the partition area, partitions, which are the management areasmanaged by the partition managers, are set and registered. In the memoryshown in FIG. 6, the partitions have already been set. However, in a newdevice, a partition area is not present since partitions are not yetset. As discussed above, the partitions are set in the memory within thedevice by the partition manager, which serves as the service entity,based on the PRT ticket issued by the partition registration ticket(PRT) issuing means (PRT Issuer) managed by the device manager accordingto a predetermined procedure, i.e., the rules set in the partitionregistration ticket (PRT).

[0249] In the device-unique-information/device-partition-informationarea, information concerning the device manufacturing entity,information concerning the device manager, set partition information,and key information required for performing the partition settingregistration processing by accessing the device, are stored. Details ofthe stored information are given below. The storage data in the deviceunique information area can be used as data corresponding to IDm(discussed below), which is the unique device value used for mutualauthentication.

[0250] As shown in FIG. 6, the partition area includes at least one fileportion, an unused portion, and apartition-unique-information/partition-file portion. In the fileportion, files, for example, files that have been set by the serviceentity, which is the partition manager, according to the services, suchas commuter tickets and prepaid tickets, are stored. In the unusedportion, new files can be set. In thepartition-unique-information/partition-file-information portion,information concerning the files in the partitions and key informationrequired for the file access processing are stored. Details of suchstorage information are given below.

[0251] [A3. Device Manager Configuration]

[0252] The configuration of the device manager is discussed below withreference to FIG. 7. The device manager is the management entity of thedevice to be provided (sold or loaned) to the user.

[0253] The device manager 200 contains the partition registration ticket(PRT) issuing means (PRT Issuer) 210, which issues the partitionregistration ticket (PRT) allowing partitions to be set as the memorydivided areas in the device in response to a request from a partitionmanager, which serves as a service entity providing the services byusing the divided partitions.

[0254] The device manager 200 also issues the device public keycertificate (CERT-DEV) corresponding to the device. The device manager200 receives a request to issue a public key certificate from thedevice, checks the received issuing request, and transfers it to thecertificate authority (CA(DEV)) 610. The device manager 200 also servesas a registration authority (RA) 220 managing the issued public keycertificate.

[0255] As shown in FIG. 7, the partition registration ticket (PRT)issuing means (PRT Issuer) 210 of the device manager 200 has controlmeans 211 and a database 212. The database 212 storesissued-partition-registration-ticket (PRT) management data, such asissued-ticket management data in which, for example, a partition manageridentifier for identifying the ticket issuer, a ticket identifier, and aticket user (ex. reader/writer, PC, etc.) are stored while being relatedto each other.

[0256] The registration authority (RA) 220 has a control means 221 andan issued-public-key-certificate management database 222, which storesissued-public-key-certificate management data, such as data in which,for example, a device identifier that has issued the public keycertificate and a public-key-certificate identifier (serial number) arestored while being related to each other.

[0257] The control means 211 of the partition registration ticket (PRT)issuing means (PRT Issuer) 210 of the device manager 200 executesissuing processing of a partition registration ticket (PRT) byperforming data communication with the partition manager. The controlmeans 221 of the registration authority (RA) 220 executes issuingprocessing of a public key certificate for the device by performingcommunication with the device and the device-manager certificateauthority (CA(DEV)) 610. Details of the above-described processings arediscussed below. The configuration of the control means 211 or 221 isdescribed below with reference to FIG. 8.

[0258] The control means 211 and 221 are both configured in a mannersimilar to a PC, which serves as, for example, data processing means,and more specifically, the control means 211 and 221 are configured asshown in FIG. 8. The configuration of the control means is as follows. Acontroller 2111 is formed of a central processing unit (CPU) thatexecutes various processing programs. A ROM (Read only Memory) 2112 is amemory storing execution processing programs, such as an encryptionprocessing program. A RAM (Random Access Memory) 2113 is used as astorage area for the programs executed by the controller 2111, forexample, a data base management program, an encryption processingprogram, a communication program, and an execution program, and is alsoused as a work area for performing the above-described processingprograms.

[0259] A display unit 2114 has display means, such as a liquid crystaldisplay or a CRT, and displays data when various programs are executed,for example, the processed data content, under the control of thecontroller 2111. An input unit 2115 has a keyboard and a pointingdevice, for example, a mouse, and outputs commands and data input fromsuch input devices to the controller 2111. An HDD (Hard Disk Drive) 2116stores programs, such as a database management program, an encryptionprocessing program, and a communication program, and various data.

[0260] A drive 2117 has the function of controlling access to variousrecording media, such as magnetic disks, for example, HDDs (Hard Disks)and FDs (Floppy Disks), optical discs, for example, CD-ROMs (CompactDisk ROMs), magneto-optical disks (mini disks), and semiconductormemory, for example, ROMs and flash memory. The various recording media,such as magnetic disks, store programs and data. A communicationinterface 2118 serves as a cable or wireless interface performingcommunication via a network, a cable connection, or a telephone line,and serves as a communication interface with the individual entities,such as the user device, the partition managers, and the certificateauthorities.

[0261] [A4. Partition Manager Configuration]

[0262] The configuration of the partition manager is discussed belowwith reference to FIG. 9. The partition manager is the management entityfor the partitions set in the device to be provided (sold or loaned) tothe user.

[0263] The partition manager 300 sets the partitions as the dividedareas in the memory of the user device by using the partitionregistration ticket (PRT) assigned from the device manager according tothe rules recorded in the assigned PRT, and then provides the servicesby using the set partitions.

[0264] Files corresponding to the services and data can be set in thepartitions. For performing the file setting processing, it is necessaryto obtain a file registration ticket (FRT), and for making data access,such as reading and writing, it is necessary to obtain a servicepermission ticket (SPT). The file setting processing and the data accessprocessing are performed by a ticket user, and more specifically, by areader/writer, which serves as a dedicated data access unit, by usingthe tickets.

[0265] The partition manager 300 includes the file registration ticket(FRT) issuing means (FRT Issuer) 310 and the service permission ticket(SPT) issuing means (SPT Issuer) 320, which serve as the ticket issuingprocessing means for the user tickets.

[0266] The partition manager 300 also issues the partition public keycertificate (CERT-PAR) for each partition of the device. The partitionmanager 300 receives a public-key-certificate issuing request from thedevice, checks the received issuing request, and then transfers thechecked request to the certificate authority (CA(PAR)) 620. Thepartition manager 300 also serves as a registration authority (RA) formanaging the issued public key certificate.

[0267] As shown in FIG. 9, the file registration ticket (FRT) issuing(FRT Issuer) 310 includes control means 311 and a database 312. Thedatabase 312 stores issued file registration ticket (FRT) managementdata, such as, issued-ticket management data in which, for example, aticket user (ex. reader/writer, PC, etc.) identifier of the ticketissuer and a ticket identifier are stored while being related to eachother.

[0268] The service permission ticket (SPT) issuing means (SPT Issuer)320 of the partition manager 300 includes control means 321 and adatabase 322. The database 322 stores issued service permission ticket(SPT) management data, such as issued-ticket management data in which,for example, a ticket user (ex. reader writer, PC, etc., as the deviceaccess unit) identifier of the ticket issuer and a ticket identifier arestored while being related to each other.

[0269] The registration authority (RA) 330 has a database 332 formanaging issued public key certificates. In the database 332,issued-public-key-certificate management data in which, for example, adevice identifier that has issued a public key certificate, a partitionidentifier, and a public-key-certificate identifier (serial number) arestored while being related to each other.

[0270] The control means 311 of the file registration ticket (FRT)issuing means (FRT Issuer) 310 of the partition manager 300 executesissuing processing of a file registration ticket (FRT) by performingdata communication with the ticket user (ex. reader/writer, PC, etc., asthe device access unit). The control means 321 of the service permissionticket (SPT) issuing means (Ticket Issuer) 320 executes issuingprocessing of a service permission ticket (SPT) by performing datacommunication with the ticket user (ex. reader/writer, PC, etc., as thedevice access unit). The control means 331 of the registration authority(RA) 330 executes issuing processing of a public key certificate for thedevice by performing communication with the device and thepartition-manager certificate authority (CA(PAR)) 620. Details of theseprocessings are discussed below.

[0271] The configuration of the control means 311, 321, and 331 of thepartition manager 300 is similar to the control means of theabove-described device manager discussed with reference to FIG. 8, andan explanation thereof is thus omitted.

[0272] [A5. Ticket User (Reader/Writer as Device Access Unit)Configuration]

[0273] The reader/writer as the device access unit is configured toperform various processings, such as device partition setting, filesetting, data reading and writing, billing-data decrementing andincrementing, etc. The processing is performed on the device accordingto the rules recorded in the corresponding partition registration ticket(PRT), the file registration ticket (FRT), or the service permissionticket (SPT). That is, all the processings to be performed on the deviceare restricted by the corresponding tickets.

[0274] An example of the configuration of the reader/writer as thedevice access unit is shown in FIG. 10. As shown in FIG. 10, areader/writer 700 includes: a CPU (Central Processing Unit) 701 having aprogram execution function and a computation processing function; acommunication interface 702 having an interface function of performingcommunication processing with external devices, such as the device andthe ticket issuing means (Ticket Issuer); a ROM (Read Only Memory) 703storing various programs to be executed by the CPU 701, for example, anencryption processing program; a RAM (Random Access Memory) 704, whichserves as a load area for programs to be executed, or a work area forthe various types of program processings; an encryption processor 705for performing encryption processing, such as authentication processingwith external devices, digital signature creation, verificationprocessing, encryption of storage data, and decoding processing; and amemory 706, which is formed of, for example, an EEPROM (ElectricallyErasable Programmable ROM), storing various key data for authenticationprocessing, encryption and decryption processing, etc., and uniqueinformation of the reader/writer.

[0275] [A6. Public Key Certificate]

[0276] In the use of the device having a memory provided with aplurality of partitions according to the present invention, whenperforming data communication among the entities, the ticket issuingmeans, the ticket users, and the devices, necessary information istransferred after checking whether both the data transmission side andthe data receiving side are an authorized sender and an authorizedreceiver. To implement a security configuration for performing such datatransfer, encryption processing, signature creation, and verificationprocessing are performed on the transfer data.

[0277] Encrypted data can be decrypted into decoded data (plaintext) bydecryption processing according to a predetermined procedure. Such adata encryption and decryption method using an encryption key forencrypting information and using a decryption key for decrypting theinformation is conventionally well known.

[0278] There are various modes for a data encryption/decryption methodusing an encryption key and a decryption key. As an example of suchmodes, a system, which is referred to as a “public key cryptosystem”, isknown. According to the public key cryptosystem, the key for the senderand the key for the receiver are different. One of the keys is used as apublic key that can be used by unspecified users, and the other key isused as a private key that is kept private. For example, the public keyis used for the encryption key, and the private key is used for thedecryption key. Alternatively, the private key is used for theauthenticator creation key, and the public key is used for theauthenticator verification key.

[0279] Unlike a so-called common key cryptosystem in which the commonkey is used for encryption and decryption, in the public keycryptosystem, the private key that has to be kept private is possessedby a single specified user, which is thus advantageous in terms of themanagement of the key. However, the data processing rate of the publickey cryptosystem is lower than that of the common key cryptosystem.Thus, the public key cryptosystem is suitable for processing a smallamount of data, such as delivering a private key and creating a digitalsignature. A typical example of the public key cryptosystem is RSA(Rivest-Shamir-Adleman) encryption. In the RSA encryption, the productof two vary large prime numbers (for example, 150 digits) is employed,and the fact that it is very difficult to perform factorization of twolarge prime factors (for example, 150 digits) is utilized.

[0280] In the public key cryptosystem, the public key can be used formany unspecified users, and a certificate that certifies the integrityof the distributed public key, i.e., a public key certificate, is oftenemployed. For example, in this system, user A creates a pair of a publickey and a private key, sends the created public key to a certificateauthority, and obtains a public key certificate from the certificateauthority. The user A opens the public key certificate to the public. Anunspecified user obtains the public key from the public key certificateaccording to the predetermined procedure, encrypts a document, and sendsit to the user A. The user A decrypts the encrypted document by usingthe private key. Also, in this system, the user A attaches a signatureto the document by using the private key, and an unspecified userobtains the public key from the public key certificate according to thepredetermined procedure, and verifies the signature.

[0281] The public key certificate is a certificate issued by acertificate authority (CA) in the public key cryptosystem. For creatingthe public key certificate, the user submits the user ID and the publickey to the certificate authority, and the certificate authority addsinformation, such as the ID of the certificate authority and thevalidity date, and the signature of the certificate authority.

[0282]FIG. 11 illustrates the overall format of the public keycertificate. The individual data items are briefly discussed below.

[0283] The version number of the certificate indicates the version ofthe public key certificate format.

[0284] The serial number of the certificate is indicated by the serialnumber (SN), which is the serial number of the public key certificateset by the public key issuing authority (certificate authority: CA).

[0285] In the signature algorithm and the algorithm parameter in thesignature algorithm identifier field, the signature algorithm of thepublic key certificate and the parameter thereof are recorded. As thesignature algorithms, the elliptic curve cryptosystem and the RSA areknown. If the elliptic curve cryptosystem is applied, the parameter andthe key length are recorded. If the RSA is applied, the key length isrecorded.

[0286] The issuing authority (certificate authority: CA) name is thefield in which the issuer of the public key certificate, i.e., the name(Issuer) of the public key certificate issuing authority (CA) isrecorded in the identifiable format (distinguished name).

[0287] In the certificate validity date, the start time and date and theend time and date, which is the validity date of the certificate, arerecorded.

[0288] In the public-key-certificate user name (subject), the ID data ofthe user to be authorized is recorded. More specifically, for example,the identifier or the category, such as the user machine ID or theservice providing entity ID, is recorded.

[0289] In the key algorithm (algorithm) and the key (subject public key)of the user public key field (Subject Public Key Info), the keyalgorithm and the key information itself are stored as the user publickey information.

[0290] In the option area, the user attribute data, and other optionaldata concerning the issuing and the usage of the public key certificateare recorded. As the attribute data, the device manager code (DMC) orthe partition manager code (PMC) as the user group information isrecorded. The user is the user of the public key certificate, forexample, the device manager, the partition manager, the ticket user, theticket issuing means, or the device.

[0291] In the option area, the category indicating the entity type orthe machine type, such as the ticket user, the ticket issuing means, thedevice, the device manager, or the partition manager, is also recordedas category information.

[0292] If the device manager also serves as the partition registrationticket issuing means (PRT Issuer),partition-registration-ticket-issuing-means code, which is discussedbelow, can be set as the device manager code (DMC). If the partitionmanager also serves as the file registration ticket issuing means andthe service permission ticket issuing means,file-registration-ticket-issuing-means code (FRTIC: FRT Issuer Code) andservice-permission-ticket-issuing-means code (SPTIC: SPT Issuer Code)can be set as the partition manager code (PMC). These codes are alsorecorded in the corresponding tickets (PRT, FRT, and SPT), which arediscussed below.

[0293] Alternatively, a unique code, which is different from the devicemanager code (DMC) or the partition manager code (PMC), may be assignedto each ticket issuing means. In this case, code is assigned by theabove-described code management institute.

[0294] The issuing authority signature is a digital signature assignedto the data of the public key certificate by using the private key ofthe public key certificate issuing authority (CA). The user of thepublic key certificate is able to check for the integrity of the publickey certificate by using the public key of the public key certificateissuing authority (CA).

[0295] A digital-signature generating method using a public keycryptosystem is described below with reference to FIG. 12. Theprocessing shown in FIG. 12 is a digital-signature-data generatingprocessing flow using EC-DSA ((Elliptic Curve Digital SignatureAlgorithm), IEEE P1363/D3). In this method, the elliptic curveCryptography (hereinafter referred to as “ECC”) is employed as thepublic key cryptosystem. In the data processing apparatus of the presentinvention, another public key cryptosystem other than the ECC, forexample, RSA encryption (Rivest, Shamir, Adleman) (ANSI X9.31) can beused.

[0296] The individual steps in FIG. 12 are as follows. In step S1, it isdetermined that p is a characteristic, a and b are coefficients of anelliptic curve (elliptic curve: y²=x³+ax+b, 4a³+27b²≠0 (mode p)), G is abase point on the elliptic curve, r is the order of G, and Ks is aprivate key (0<Ks<r). In step S2, the hash value of message M iscalculated and is set to f=Hash(M).

[0297] A technique for determining the hash value by using a hashfunction is discussed below. The hash function is a function forinputting a message, compressing the message into a predetermined lengthof data, and outputting it as a hash value. In the hash function, it isdifficult to predict the input from the hash value (output), and whenone bit of the data input into the hash function changes, many bits ofthe hash value change. It is also difficult to find different input datahaving the same hash value. As the hash function, MD4, MD5, or SHA-1 maybe used, and DES-CBC may be used. In this case, MAC (check value:corresponding to ICV), which is the final output value, is the hashvalue.

[0298] Subsequently, in step S3, a random number u (0<u<r) is generated,and in step S4, coordinates V (X_(V), Y_(V)) obtained by multiplying thebase point by u are calculated. The addition and the multiplication bytwo on the elliptic curve are defined as follows.

[0299] It is now assumed that P=(Xa, Ya), Q=(Xb, Yb), and R=(Xc,Yc)=P+Q.

[0300] When P≠Q (addition),

Xc=λ² −Xa−Xb

Yc=λ×(Xa−Xc)−Ya

λ=(Yb−Ya)/(Xb−Xa).

[0301] When P=Q (multiplication by two),

Xc=λ ²−2Xa

Yc=λ×(Xa−Xc)−Ya

λ=(3(Xa)² +a/(2Ya).

[0302] By using these factors, the value obtained by multiplying thepoint G by u is calculated (the simplest calculation method although thespeed is slow is as follows: G, 2×G, 4×G, . . . are calculated, u isexpanded into a binary format, 2^(i)×G (value obtained by two to thepower of i (i is the bit position counted from the LSB of u) is appliedto the bit positions having the value of 1, and the resulting values areadded.

[0303] In step S5, c=X_(V)mod r is calculated, and it is determined instep S6 whether c is 0. If c is not 0, d=[(f+cKs)/u]mod r is calculatedin step S7. Then, it is determined in step S8 whether d is 0. If d isnot 0, c and d are output as digital signature data in step S9. If it isassumed that r has a length of 160 bits, the digital signature data has320 bits.

[0304] If it is found in step S6 that c is 0, the process returns tostep S3, and a new random number is re-generated. Similarly, if it isfound in step S8 that d is 0, the process returns to step S3, and arandom number is re-generated.

[0305] A technique for verifying a digital signature using a public keycryptosystem is described below with reference to FIG. 13. In step S11,it is determined that M is a message, p is a characteristic, a and b arecoefficients of an elliptic curve (elliptic curve: y²=x³+ax+b,4a³+27b²≠0 (mode p)), G is a base point on the elliptic curve, r is theorder of G, Ks is a private key (0<ks<r), and G and Ks×G are a publickey (0<Ks<r). It is determined in step S12 whether digital signaturedata c and d satisfy 0<c<r and 0<d<r, respectively. If they aresatisfied, in step S13, the hash value of the message M is calculated,and is set to f=Hash(M). Then, in step S14, h=1/d mod r is calculated,and in step S15, h1=fh mod r, h2=ch mod r are calculated.

[0306] In step S16, point P=(Xp, Yp)=h1×G+h2·Ks×G is calculated by h1and h2 which have already been calculated. Since the digital signatureverifier knows the base point G and Ks×G, it is possible to calculatethe scalar product of the point on the elliptic curve, as in a mannersimilar to step S4 of FIG. 12. It is then determined in step S17 whetherthe point P is a point at infinity. If it is not a point at infinity,the process proceeds to step S18 (in reality, a determination as towhether the point P is a point at infinity can be made in step S16, thatis, when P=(X, Y) and Q=(X, −Y) are added, λ cannot be calculated, andit is thus proved that P+Q is a point at infinity). In step S18, Xp modr is calculated, and is compared with the digital signature data c. Ifthe two values are the same, the process proceeds to step S19 in whichit is determined that the digital signature is correct.

[0307] When the digital signature is found to be correct, it can beproved that the data has not been tampered with, and that the digitalsignature has been generated by the entity which has the secret keycorresponding to the public key.

[0308] If the digital signature data c or d does not satisfy 0<c<r or0<d<r in step S12, the process proceeds to step S20. If the point P isfound to be a point at infinity in step S18, the process also proceedsto step S20. If Xp mod r is not equal to the digital signature data c instep S18, the process also proceeds to step S20.

[0309] When it is determined in step S20 that the digital signature isnot correct, it can be proved that the data has been tampered with, orthe digital signature has not been generated by the entity which has theprivate key corresponding to the public key.

[0310] In the system of the present invention, the device public keycertificate (CERT-DEV) issued to the device via the device-managermanagement registration authority is stored in the device, and thepartition public key certificate (CERT-PAR) issued to each devicepartition via the partition-manager management registration authority isstored in the corresponding partition. These public key certificates areused for performing mutual authentication, signature creation, andverification processing between the ticket user (ex. reader/writer asthe device access unit) and the device when performing the processing onthe device, i.e., the partition registration setting processing usingthe partition registration ticket (PRT), the file registration settingprocessing using the file registration ticket (FRT), and the dataprocessing using the service permission ticket (SPT). Specific examplesof these processings are discussed below by using flows.

[0311] [A7. Storage Data in Device Memory]

[0312] The storage data in the device having partitioned memory areas ofthe present invention is described below. As previously discussed withreference to FIG. 6, the device contains a memory, which is formed of,for example, an EEPROM. As the main areas, the memory has a partitionarea, an unused area, and adevice-unique-information/device-partition-information area. The storagedata in the individual areas are sequentially described below withreference to the drawing.

[0313] (A7.1. Device-Unique-Information/Device-Partition-InformationArea)

[0314] Data in thedevice-unique-information/device-partition-information area is firstdiscussed. In the device-unique-information/device-partition-informationarea, information concerning the device manufacturing entity,information concerning the device manager, setting partitioninformation, key information required for executing the partitionsetting registration processing by accessing the device, etc., arestored.

[0315]FIG. 14 illustrates the data structure of a manufactureinformation block. The number in each portion indicates the number ofbytes. As discussed with reference to FIG. 6, one block has 32 bytes inthe configuration of this embodiment. In the gray portions in FIG. 14,data may be encrypted or unencrypted.

[0316] The following items of data are stored in the manufactureinformation block:

[0317] Writable Flag: determination flag indicating whether the writingoperation into the block is allowed (ex. 0xffff: allowed, others: notallowed);

[0318] Manufacture Code: card manufacturer ID number

[0319] Manufacture Equipment Code: card manufacture line number;

[0320] Manufacture Date: card manufacture date, for example, Jan. 1,2001 being set to 0x0000;

[0321] Manufacture Serial Number: card manufacture serial number;

[0322] Device Vender Code: IC chip supply company number;

[0323] Device Code: IC chip model number; and

[0324] Device Parameter: other parameters.

[0325] Since these items of information written into the block areunique, the device unique identifier is defined as IDm based on theseitems of information. The device unique identifier may be acquired fromthe whole information or part of the information written into themanufacture information block, or from computed data obtained from thewritten information.

[0326]FIG. 15 illustrates the data configuration of the devicemanagement information block. The following items of data are stored inthe device management information block:

[0327] Writable Flag: determination flag whether the writing operationinto the block is allowed (ex. 0xffff: allowed, others: not allowed);

[0328] DMC (Device Manager Code): device manager (DM) ID number;

[0329] DMC Version: device manager code (DMC) version, which is used as,for example, comparison conditions when updating the DMC;

[0330] Total Block Number in Device: the number of all the blocks in thedevice;

[0331] Free Block Number in Device: the number of free blocks in thedevice;

[0332] Partition Number: the number of currently registered partitions;and

[0333] Pointer of Free Area: the pointer of the free area.

[0334]FIG. 16 illustrates the data configuration of the public-keydevice key definition block (Device Key Definition Block (PUB)). Thefollowing items of data are stored in the device key definition block(PUB):

[0335] PUB_CA(DEV) Pointer: the pointer to the block in which the publickey of the device-manager certificate authority (CA(DEV)) that issues apublic key certificate via a registration authority managed by thedevice manager is stored;

[0336] PUB_CA(DEV) Size: the size of the public key of the certificateauthority CA(DEV);

[0337] PRI_DEV Pointer: the pointer to the block in which the privatekey of the device is stored;

[0338] PRI_DEV Size: the size of the private key of the device;

[0339] PARAM_DEV Pointer: the pointer to the block in which the publickey parameter of the device is stored;

[0340] PARAM_DEV Size: the size of the public key parameter of thedevice;

[0341] CERT_DEV Pointer: the pointer to the block in which the publickey certificate of the device issued by the certificate authorityCA(DEV) is stored;

[0342] CERT_DEV Size: the size of the public key certificate of thedevice issued by the certificate authority CA(DEV);

[0343] CRL_DEV Pointer: the pointer to the block in which the revocationlist of the device is stored;

[0344] CRL_DEV Size: the size of the revocation list of the device;

[0345] PRTIC (PRT Issuer Category): the issuer category of the partitionregistration ticket (RPT);

[0346] PRTIC Version: the version of the issuer category (PRTIC) of thepartition registration ticket (PRT);

[0347] DUTIC_DEV (DUT Issuer Category): the issuer category of the dataupdate ticket (DUT); and

[0348] DUTIC_DEV Version: the version of the data update ticket (DUT)issuer (DUTIC).

[0349] The revocation list in the above-mentioned data items is a listof unauthorized devices, for example, a device revocation list issued bythe issuer of a device distribution system, or a list of ID dataindicating unauthorized devices. If a device which is set in areader/writer as the device access unit is posted in the revocationlist, the processing is terminated.

[0350] For example, the latest revocation list is constantly distributedto all the readers/writers as the device access units, and thereader/writer determines whether the processing is to be executed orterminated by checking the list when performing the processing for thedevice. Alternatively, the reader/writer views the latest revocationlist via a network by using a communication function of thereader/writer so as to obtain unauthorized device information indicatedin the list, thereby determining whether the processing is to beexecuted or terminated. The specific processing using the revocationlist is described below by using a flow.

[0351] The data update ticket (DUT) in the above-mentioned data items isan access restricting ticket for permitting and restricting the updatingprocessing when updating various data stored in the device. Access rulesfor the device are recorded in the data update ticket, as in theabove-described PRT, FRT, and SPT. The data update ticket (DUT) isdiscussed in detail below.

[0352]FIG. 17 illustrates the data structure of the common-key devicekey definition block (Device Key Definition Block (Common)). Thefollowing items of data are stored in the common key definition block(Common):

[0353] Mkauth_DEV_A Pointer: the pointer to a two-way individual keyauthentication master key (MKauth_DEV_A);

[0354] Mkauth_DEV A Size: the size of the two-way individual keyauthentication master key (MKauth_DEV_A);

[0355] Kauth_DEV_B Pointer: the pointer to a two-way individual keyauthentication key (Kauth_DEV_B);

[0356] Kauth_DEV_B Size: the size of the two-way individual keyauthentication key (Kauth_DEV_B);

[0357] Kprt Pointer: the pointer to the block in which the MAC checkingkey (Kprt) for the partition registration ticket (PRT) is stored;

[0358] Kprt Size: the size of the MAC checking key (Kprt) for thepartition registration ticket (PRT);

[0359] Kdut_DEV1-4 Pointer: the pointer to the block in which the MACchecking key (Kdut) for the data update ticket (DUT) is stored;

[0360] Kdut_DEV1-4 Size: the size of the MAC checking key (Kdut) for thedata update ticket (DUT);

[0361] IRL_DEV Pointer: the pointer to the block in which the device IDsof the unauthorized devices are stored as the revocation list of thedevices; and

[0362] IRL_DEV Size: the size of the revocation list of the devices.

[0363] The authentication method for the two-way individual key and thechecking processing for the MAC (Message Authentication Code) in theabove-mentioned data items are described in detail below.

[0364] There are four types of Kdut_DEV, which are used by pairs, suchas (Kdut_DEV1, Kdut_DEV2) and (Kdut_DEV3, Kdut_DEV4). For example,Kdut_DEV1, 3 are used for MAC generation, and the Kdut_DEV2, 4 are usedfor encryption.

[0365]FIG. 18 illustrates the data structure of a device key area. Thefollowing items of data are stored in the device key area. In each keystored in the device key area, version information is stored together.When updating a key, the version is updated together.

[0366] IRL_DEV: the revocation list (device ID) in which the IDs ofrevoked devices and revoked units (a reader/writer as a device accessunit, a ticket user, such as a PC, or ticket issuing means) areregistered;

[0367] CRL_DEV: the revocation list (certificate) in which the publickey certificate identifiers (ex. serial number: SN) of revoked devicesand revoked units (a reader/writer as a device access unit, a ticketuser, such as a PC, or ticket issuing means) are registered;

[0368] Kdut_DEV1: the MAC checking key for the data update ticket (DUT);

[0369] Kdut_DEV2: the data updating encryption key;

[0370] Kdut_DEV3: the MAC checking key for the data update ticket (DUT);

[0371] Kdut_DEV4: the data updating encryption key;

[0372] Kprt: the MAC checking key for the partition registration ticket(PRT);

[0373] CERT_DEV: the device public key certificate issued by thecertificate authority CA(DEV) that issues the device-manager public key;

[0374] PRI_DEV: the private key of the device;

[0375] PARAM_DEV: the public key parameter of the device;

[0376] PUB_CA(DEV): the public key of the certificate authority CA(DEV)that issues the device-manager public key;

[0377] Kauth_DEV_B: the two-way individual key authentication commonkey; and

[0378] MKauth_DEV_A: the two-way individual key authentication masterkey.

[0379] In the device key area shown in FIG. 18, Kauth_DEV_A: the two-wayindividual key authentication common key and MKauth_DEV_B: the two-wayindividual key authentication master key are stored. However, these keysdo not have to be stored if the device does not receive a request toperform common key authentication processing. Also, if the device doesnot perform the ticket checking processing, Kprt: the MAC checking keyfor the partition registration ticket (PRT) does not have to be stored.

[0380] IRL_DEV: the revocation list (device ID) in which the device IDsof revoked devices are registered and CRL_DEV: the revocation list(certificate) in which the public key certificate identifiers (ex.serial number: SN) of revoked devices are registered do not have to bestored if there is no revoked device, or if the revocation lists areobtained by using another source.

[0381]FIG. 19 illustrates the data structure of the partition definitionblock. The following items of data are stored in the partitiondefinition block.

[0382] PMC (Partition Manager Code): the code (PMC) assigned to thepartition manager, for example, the number;

[0383] PMC Version: the version of the partition manager code (PMC);

[0384] Partition Start Position: the partition storage start address;and

[0385] Partition Size: the size of the partition.

[0386] The above-described items are the data items stored in thedevice-unique-information/device-partition-information area of thedevice memory.

[0387] (A7.2. Partition Area)

[0388] The data items in the partition area are now discussed. Thepartition area is the area managed by a partition manager. As discussedabove, a partition manager, which serves as a service entity, storesdata in the device memory according to the predetermined procedure,i.e., the rules set in the partition registration ticket (PRT) based onthe PRT ticket issued by the partition registration ticket (PRT) issuingmeans (PRT Issuer). The data configuration of the partition area is asfollows.

[0389]FIG. 20 illustrates the data structure of the partition managementinformation block. The following items of data are stored in thepartition management information block:

[0390] PMC (partition manager code): the number of the partitionpossessor;

[0391] PMC Version: the version of the partition manager code (PMC);

[0392] Total Block Number in Partition: the number of all the blocks inthe partition;

[0393] Free Block Number in Partition: the number of free blocks in thepartition;

[0394] Pointer of Free Area: the pointer to the unused area in thepartition; and

[0395] File Number: the number of files currently registered in thepartition.

[0396]FIG. 21 illustrates the data structure of the public-key partitionkey information block (Partition Key Definition Block (PUB)). Thefollowing items of data are stored in the public-key partition keyinformation block (Partition Key Definition Block (PUB)):

[0397] PUB_CA(PAR) Pointer: the pointer to the block in which the publickey of the certificate authority CA(PAR) that issues the public keycertificate via the partition-manager registration authority is stored;

[0398] PUB_CA(PAR) Size: the size of the public key of the certificateauthority CA(PAR);

[0399] PRI_PAR Pointer: the pointer to the block in which the privatekey of the partition is stored;

[0400] PRI_PAR Size: the size of the private key of the partition;

[0401] PARAM_PAR Pointer: the pointer to the block in which the publickey parameter of the partition is stored;

[0402] PARAM_PAR Size: the size of the public key parameter of thepartition;

[0403] CERT_PAR Pointer: the pointer to the block in which the publickey certificate of the partition issued by the certificate authorityCA(PAR);

[0404] CERT_PAR Size: the size of the public key certificate of thepartition issued by the certificate authority CA(PAR);

[0405] CRL_PAR Pointer: the pointer to the block in which the revocationlist of the partition is stored;

[0406] CRL_PAR Size: the size of the revocation list of the partition;

[0407] FRTIC (FRT Issuer Category): the file registration ticket (FRT)issuer category;

[0408] FRTIC Version: the version of the file registration ticket (FRT)issuer category (PRTIC);

[0409] DUTIC_PAR (DUT Issuer Category): the data update ticket (DUT)issuer category; and

[0410] DUTIC_PAR Version: the version of the data update ticket (DUT)issuer category (DUTTC).

[0411]FIG. 22 illustrates the data structure of the common-key partitionkey information block (Partition Key Definition Block (Common)). Thefollowing data items are stored in the common-key partition keyinformation block (partition Key Definition Block (Common)):

[0412] Mkauth_PAR_A Pointer: the pointer to the two-way individual keyauthentication master key (MKauth_PAR_A);

[0413] Mkauth_PAR_A Size: the size of the two-way individual keyauthentication master key (MKauth_PAR_A);

[0414] Kauth_PAR_B Pointer: the pointer to the two-way individual keyauthentication key (Kauth_PAR_B);

[0415] Kauth_PAR_B Size: the size of the two-way individual keyauthentication key (Kauth_PAR_B);

[0416] Kfrt Pointer: the pointer to the block in which the MAC checkingkey (Kfrt) for the file registration ticket (FRT) is stored;

[0417] Kfrt Size: the size of the MAC checking key (Kfrt) for the fileregistration ticket (FRT);

[0418] Kdut_PAR1-4 Pointer: the pointer to the block in which the MACchecking key (Kdut) for the data update ticket (DUT) is stored;

[0419] KDUT_PAR1-4 Size; the size of the MAC checking key (Kdut) for thedata update ticket (DUT);

[0420] IRL_PAR Pointer: the pointer to the block in which the partitionrevoked-device-ID revocation list (Revocation List-Device ID) is stored;and

[0421] IRL_PAR Size: the size of the partition revoked-device-IDrevocation list (Revocation List-Device ID).

[0422] The two-way individual key authentication method and the MAC(Message Authentication Code) checking method in the above-mentioneddata items are described in detail below.

[0423] There are four types of Kdut_PAR, which are used as pairs, suchas (Kdut_PAR1, Kdut_PAR2) and (Kdut_PAR3, Kdut_PAR4). For example,Kdut_PAR1, 3 are used for MAC generation, and Kdut_PAR2, 4 are used forencryption.

[0424]FIG. 23 illustrates the data structure of the partition key area.The following items of data are stored in the partition key area. Ineach key stored in the partition key area, version information is storedtogether. When updating a key, the version is updated together.

[0425] IRL_PAR: the revocation list (Revocation List (Device ID)) inwhich the identifiers (IDs) of the partition access revoked devices andthe partition access revoked units (a reader/writer as a device accessunit, a ticket user, such as a PC, or ticket issuing means) areregistered;

[0426] CRL_PAR: the revocation list (Revocation list (Certificate)) inwhich the public key certificate identifiers (ex. serial number: SN) ofthe partition access revoked devices and the partition access revokedunits (a reader/writer as a device access unit, a ticket user, such as aPC, or ticket issuing means) are registered;

[0427] Kdut_PAR1: the MAC checking key for the data update ticket (DUT);

[0428] Kdut_PAR2: the data updating encryption key:

[0429] Kdut_PAR3: the MAC checking key for the data update ticket (DUT);

[0430] Kdut_PAR4: data updating encryption key;

[0431] Kfrt: the MAC checking key for the file registration ticket(FRT);

[0432] CERT_PAR: the public key certificate of the partition issued bythe certificate authority CA(PAR);

[0433] PRI_PAR: the private key of the partition;

[0434] PARAM_PAR: the public key parameter of the partition;

[0435] PUB_CA(PAR): the public key of the certificate authority CA(PAR);

[0436] Mkauth_PAR_A: the two-way individual key authentication masterkey; and

[0437] Kauth_PAR_B: the two-way individual key authentication commonkey.

[0438]FIG. 24 illustrates the data structure of the file definitionblock (FDB). The following data items are stored in the file definitionblock:

[0439] File ID: the file identifier name;

[0440] File Start Position: the file start address;

[0441] File Size: the file size;

[0442] SPTIC (SPT Issuer Category): the service permission ticket (SPT)issuer category (SPTIC);

[0443] SPTIC Version: the version of the service permission ticket (SPT)issuer category (SPTIC);

[0444] File Structure Type code: the code of the file structure type;

[0445] Acceptable Authentication Type: the acceptable authenticationtype in which the access modes defined for the individual file structuretypes are associated with the corresponding bits in this field (amaximum of 16 pairs in this example) (details are as follows);

[0446] Acceptable Verification Type: the acceptable verification type inwhich the access modes defined for the individual file structure typesare associated with the corresponding bits in this field (a maximum of16 pairs in this example) (details are as follows); and

[0447] Kspt: the MAC checking key (Kspt) for the service permissionticket (SPT).

[0448] The acceptable authentication type is the type in which theaccess modes defined for the individual file structure types areassociated with the corresponding bits in this field (a maximum of 16pairs in this example). For example, when executing a certain accessmode, and if the bit corresponding to this mode is 1, the access mode isnot executed if the public key is not authenticated. Accordingly, whenexecuting a command having a higher degree of the importance (forexample, money depositing processing), the public key must beauthenticated, thereby ensuring the security. It may be controlled toperform the above-described processing by using the tickets. However,unlike the tickets, the acceptable authentication type is stored in thedevice as part of the file definition block, and this information cannotbe changed after the file is created. Thus, the acceptableauthentication type can be used when a strong restriction is desirablyimposed by prohibiting a change in the acceptable authentication type,and then, the minimal degree of security can be ensured.

[0449] The above-described acceptable verification type is the type inwhich the access modes defined for the individual file structure typesare associated with the corresponding bits in this field (a maximum of16 pairs in this example). For example, when executing a certain accessmode, and if the bit corresponding to this mode is 1, the access mode isnot executed if the ticket is not verified according to a public keycryptosystem. In this example, each field has two bytes, and thus, amaximum of 16 access modes are associated with the corresponding bits.However, by increasing the field size according to the necessity, morecommands can be associated.

[0450] In this embodiment, in the acceptable authentication type or theacceptable verification type, when the bit is 1, the authentication orverification using a public key system is required. Alternatively, eachfield may be set to 2 bits, and the settings may be made more precisely,for example, as follows. When the value is “11”, the authentication orverification using a public key system is required; when the value is“01”, the authentication or verification using a common key system isrequired, and when the value is “00” or “10”, the authentication orverification using either a public key system or a common key system isrequired.

[0451] The file structure type in the above-described data items is thecode indicating the file structure created in the partition. An exampleof the relationship between the file structure and the code is shown inFIG. 25.

[0452] As the file structure, there are various structures shown in FIG.25, and codes 0001 through 0007 are assigned. The meanings of theindividual files structures are as follows:

[0453] Random: all the data having this file structure can be randomlyread and written;

[0454] Purse: the data having this file structure is billing informationdata, which can be changed, such as subtracted and added;

[0455] Cyclic: the data having this file structure can be cyclicallywritten;

[0456] Log: the data having this file structure is a log data file, or arecording information file concerning each data processing information;

[0457] Key: the data file having this file structure is a keyinformation file; and

[0458] Composite file: a file having a composite structure of theabove-described various files (ex. Purse and Log), and different codesare assigned to the composite files according to the combination pattern(in FIG. 25, 0006: composite file 1 and 0007: composite file 2).

[0459] The data stored in the device memory have been discussed asabove. The specific processing using the data is discussed below.

[0460] [A8. Data Format of Each Ticket]

[0461] As discussed above, for performing the partition settingregistration processing for the device, the partition registrationticket (PRT) issued by authorized ticket issuing means (Ticket Issuer)is required. For performing the file setting registration processing inthe partitions set in the device, the file registration ticket (FRT)issued by authorized ticket issuing means (Ticket Issuer) is required.For accessing a file, the service permission ticket (SPT) issued byauthorized ticket issuing means (Ticket Issuer) is required. As has beenbriefly discussed in the column of Storage Data in Memory Device, thedata update ticket (DUT) is required for updating the device storagedata.

[0462] Each ticket is formed of a data string in which the device accessrules are indicated as binary data. The ticket is sent to the devicefrom, for example, a reader/writer, which is a ticket user as the deviceaccess unit, according to the processing to be performed on the device.Upon receiving the ticket, the device performs the verificationprocessing for the integrity of the ticket, and if the verification issuccessfully performed, various processings (ex. partition creation,file creation, and data access) are executed according to the rulesrecorded in the ticket. The data formats of these tickets are asfollows.

[0463] (A8.1. Partition Registration Ticket (PRT))

[0464] The partition registration ticket (PRT) is the access controlticket used for performing the partition setting registration processingfor the device. The device is accessed by a ticket user (ex.reader/writer as a device access unit) under the management of thepartition manager by using the PRT issued by ticket issuing means(Ticket Issuer) managed by an authorized device manager according to theprocedure recorded in the PRT, thereby making it possible to set thepartitions within the permission recorded in the PRT.

[0465]FIG. 26 illustrates the data format of the partition registrationticket (PRT). The following items of data are stored in the partitionregistration ticket (PRT):

[0466] Ticket Type: the type of ticket;

[0467] Format Version: the format version of the ticket;

[0468] Ticket Issuer: the identifier of the device manager (=DMC);

[0469] Serial Number: the serial number of the ticket;

[0470] Size of Ticket: the size of the ticket;

[0471] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket;

[0472] Ticket User Group: the group to which the ticket user belongs;

[0473] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device;

[0474] Ticket User Identifier: ID data (category or identifier) fordetermining the ticket user,

[0475] this field being associated with [Authentication Type] (when[Authentication Type] is the public key authentication, the ID name (DN:Distinguished Name), the category, or the serial number (SN) is stored;when [Authentication Type] is the common key authentication, theauthentication ID is stored; and when authentication is not required, itis not essential that ID data be stored);

[0476] PMC: the code indicated in the partition definition block as thepartition manager code;

[0477] PMC Version: the version of the partition manager code (PMC);

[0478] Operation Type: specifying whether the partition is generated ordeleted ((Generate)/(Delete));

[0479] Partition Size: the size of the partition;

[0480] Integrity Check Type: the type of integrity check value of theticket (public key system (Public)/common key system (Common)); and

[0481] Integrity Check Value: the integrity check value of the ticket(public key system: (signature), and common key system: (MAC)).

[0482] When sending the ticket issued by the partition registrationticket (PRT) issuing means (PRT Issuer) to the ticket user, the publickey certificate (CERT_PRTI) of the partition registration ticket (PRT)issuing means (PRT Issuer) is also sent together with the ticket if thepublic key system is employed. The attribute of the public keycertificate (CERT_PRTI) of the PRT issuing means coincides with theidentifier (PRTIC) of the PRT issuing means (PRT Issuer).

[0483] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether the public key system orthe common key system is to be performed, or whether either system is tobe allowed are recorded, though details are described below.

[0484] In the [Integrity Check Value] field in which the integrity checkvalue (public key system: signature, common key system: MAC) of theticket is recorded, the signature based on the private key of thepartition registration ticket issuing means (PRT Issuer) is generated(see FIG. 12) and stored if the public key system is employed. If thedevice manager also serves as the partition registration ticket issuingmeans (PRT Issuer), the signature is generated by using the private keyof the device manager. When performing signature verification processing(see FIG. 13), the public key of the corresponding CA(DEV) is used.Accordingly, it is necessary for the device which performs the ticketverification to obtain the public key (public key certificate) of thepartition registration ticket issuing means (PRT Issuer) (ex. devicemanager) when or before receiving the ticket.

[0485] After verifying the public key certificate (CERT_PRTI) of thepartition registration ticket (PRT) issuing means (PRT Issuer), thesignature of the ICV (integrity check value) can be verified by usingthe public key of the partition registration ticket (PRT) issuing means(PRT Issuer) extracted from the public key certificate (CERT_PRTI).These processings are discussed below by using flows.

[0486] (A8.2. File Registration Ticket (FRT))

[0487] The file registration ticket (FRT) is the access control ticketused for setting and registering files in the partitions set in thedevice. The ticket user (ex. reader/writer as a device access unit)accesses the device by using the FRT issued by the ticket issuing means(Ticket Issuer) managed by an authorized partition manager according tothe procedure recorded in the FRT, thereby making it possible to set thefiles within the permission recorded in the FRT.

[0488]FIG. 27 illustrates the data format of the file registrationticket (FRT). The following items of data are stored in the fileregistration ticket (FRT):

[0489] Ticket Type: the type of ticket;

[0490] Format Version: the format version of the ticket;

[0491] Ticket Issuer: the identifier of the partition manager (=PMC);

[0492] Serial Number: the serial number of the ticket;

[0493] Size of Ticket: the size of the ticket;

[0494] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket;

[0495] Ticket User Group: the group to which the ticket user belongs;

[0496] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device;

[0497] Ticket User Identifier: ID data (category or identifier) fordetermining the ticket user,

[0498] this field being associated with [Authentication Type] (when[Authentication Type] is the public key authentication, the ID name (DN:Distinguished Name), the category, or the serial number (SN) is stored;when [Authentication Type] is the common key authentication, theauthentication ID is stored; and when authentication is not required, itis not essential that ID data be stored);

[0499] SPTIC: the code of the service permission ticket issuing means;

[0500] SPTIC Ver: the version of the code (SPTIC) of the servicepermission ticket issuing means;

[0501] File ID: the identifier (ID) of the file created in thepartition;

[0502] Operation Type: specifying whether the file is generated ordeleted ((Generate)/(Delete));

[0503] File Size: the size of the file to be created;

[0504] File Structure: the file structure of the file to be created;

[0505] Acceptable Authentication Type: the bit string indicating thetype of authentication (public key system, or either a public key systemor a common key system is allowed) required for executing the accessmode corresponding to the file defined in this ticket;

[0506] Acceptable Verification Type: the bit string indicating the typeof verification (public key system, or either a public key system or acommon key system is allowed) for the service permission ticket (SPT)required for executing the access mode corresponding to the file definedin this ticket;

[0507] Kspt_Encrypted: the data Kfrt(Kspt) obtained by encrypting theMAC checking key Kspt for the service permission ticket (SPT) indicatedin the file definition block with the MAC checking key Kfrt for the fileregistration ticket for the same partition as the service permissionticket (SPT);

[0508] Integrity Check Type: the type of integrity check value of theticket (public key system (Public)/common key system (Common)); and

[0509] Integrity Check Value: the integrity check value of the ticket(public key system: (signature), and common key system: (MAC)).

[0510] When sending the ticket issued by the file registration ticket(FRT) issuing means (FRT Issuer) to the ticket user, the public keycertificate (CERT_FRTI) of the file registration ticket (FRT) issuingmeans (FRT Issuer) is sent together with the ticket if the public keysystem is employed. The attribute of the public key certificate(CERT_FRTI) of the FRT issuing means coincides with the identifier(FRTIC) of the file registration ticket (FRT) issuing means (FRTIssuer).

[0511] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether a public key system or acommon key system is to be performed, or whether either system is to beallowed are recorded, though details are described below.

[0512] In the [Integrity Check Value] field in which the integrity checkvalue (public key system: signature, common key system: MAC) of theticket is recorded, the signature based on the private key of the fileregistration ticket issuing means (FRT Issuer) is generated (see FIG.12) and stored if the public key system is employed. If the partitionmanager also serves as the file registration ticket issuing means (FRTIssuer), the signature is generated by using the private key of the filepartition manager. When performing the signature verification processing(see FIG. 13), the public key of the file registration ticket issuingmeans is used. Accordingly, it is necessary for the device whichperforms the ticket verification to obtain the public key (public keycertificate) of the file registration ticket issuing means (FRT Issuer)(ex. partition manager) when or before receiving the ticket.

[0513] After verifying the public key certificate (CERT_FRTI) of thefile registration ticket (FRT) issuing means (FRT Issuer), the signatureof the ICV (integrity check value) can be verified by using the publickey of the file registration ticket (FRT) issuing means (FRT Issuer)extracted from the public key certificate (CERT_PRTI). These processingsare discussed below by using flows.

[0514] (A8.3. Service Permission Ticket (SPT))

[0515] The service permission ticket (SPT) is the access control ticketused for accessing the data items in the partition set in the device andfor performing processing, such as data reading, data writing, andadding and subtracting billing data. The ticket user (ex. reader/writeras a device access unit) accesses the device by using the SPT issued bythe ticket issuing means (Ticket Issuer) managed by an authorizedpartition manager according to the procedure recorded in the SPT,thereby making it possible to perform data processing within thepermission recorded in the SPT.

[0516] The service permission ticket (SPT) has two types: one type inwhich access is allowed to only one file among the files set in thepartition, and the other type in which access is allowed to a pluralityof files among the files set in the partition. The two types aredescribed below.

[0517]FIG. 28 illustrates the data format of the service permissionticket (SPT) of the type in which access is allowed to only one fileamong the files set in the partition. The following items of data arestored in the service permission ticket (SPT):

[0518] Ticket Type: the type of ticket;

[0519] Format Version: the format version of the ticket;

[0520] Ticket Issuer: the identifier of the partition manager (=PMC);

[0521] Serial Number: the serial number of the ticket;

[0522] Size of Ticket: the size of the ticket;

[0523] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket;

[0524] Ticket User Group: the group to which the ticket user belongs;

[0525] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device;

[0526] Ticket User Identifier: ID data (category or identifier) fordetermining the ticket user,

[0527] this field being associated with [Authentication Type] (when[Authentication Type] is the public key authentication, the ID name (DN:Distinguished Name), the category, or the serial number (SN) is stored;when [Authentication Type] is the common key authentication, theauthentication ID is stored; and when authentication is not required, itis not essential that ID data be stored);

[0528] File ID: the identifier (ID) of the access file in the partition;

[0529] File Access Mode: the access mode of the file to be accessed;

[0530] Integrity Check Type: the type of integrity check value of theticket (public key system (Public)/common key system (Common)); and

[0531] Integrity Check Value: the integrity check value of the ticket(public key system: (signature), and common key system: (MAC)).

[0532] When sending the ticket issued by the service permission ticket(SPT) issuing means (SPT Issuer) to the ticket user, the public keycertificate (CERT_SPTI) of the service permission ticket (SPT) issuingmeans (SPT Issuer) is sent together with the ticket if the public keysystem is employed. The attribute of the public key certificate(CERT_SPTI) of the SPT issuing means coincides with the identifier(SPTIC) of the SPT issuing means (SPT Issuer).

[0533] If the partition manager also serves as the service permissionticket (SPT) issuing means (SPT Issuer), the code of the servicepermission ticket (SPT) issuing means (SPT Issuer) may be set as thepartition manager code (PMC).

[0534] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether the public key system orthe common key system is to be performed or whether either system is tobe allowed are recorded, though details are described below.

[0535] In the [Integrity Check Value] field in which the integrity checkvalue (public key system: signature, common key system: MAC) of theticket is recorded, the signature based on the private key of theservice permission ticket issuing means (SPT Issuer) is generated (seeFIG. 12) and stored if the public key system is employed. If thepartition manager also serves as the service permission ticket issuingmeans (SPT Issuer), the signature is generated by using the private keyof the partition manager. When performing the signature verificationprocessing (see FIG. 13), the public key of the service permissionticket (SPT) issuing means (SPT Issuer) is used. Accordingly, it isnecessary for the device which performs the ticket verification toobtain the public key (public key certificate) of the service permissionticket issuing means (SPT Issuer) (ex. partition manager) when or beforereceiving the ticket.

[0536] After verifying the public key certificate (CERT_SPTI) of theservice permission ticket (SPT) issuing means (SPT Issuer), thesignature of the ICV (integrity check value) can be verified by usingthe public key of the service permission ticket (SPT) issuing means (SPTIssuer) extracted from the public key certificate (CERT_SPTI). Theseprocessings are discussed below by using flows.

[0537] In the description of the ticket format, the access modes to berecorded in the File Access Mode, which is the access mode of the fileto be accessed, are discussed below with reference to FIG. 29.

[0538] The data to be created as files include various types of data,such as user ID data, billing data, encryption processing key data, logdata, and composite file data. Access processing corresponding to eachitem, such as data reading, data writing, deleting, adding, subtracting,encryption, or decryption, is performed on the access data.

[0539] The file access mode of the service permission ticket (SPT)defines the type of access mode to be allowed among the above-describedvarious access modes. A list of access modes is shown in FIG. 29. Theaccess modes shown in FIG. 29 are example only, and other access modescorresponding to the data to be stored in the device can be set.

[0540] The processing defined in the file access mode can be executed onthe file indicated by the [File ID: the identifier (ID) of the accessfile in the partition] set in the service permission ticket (SPT). Ifthe file access mode set in the service permission ticket (SPT) is Read,the data in the file can be read. If the file access mode set in theservice permission ticket (SPT) is Write, data can be written into thedata in the file.

[0541] The mode that can be set in the access mode is restricted by theabove-described file structure (see FIG. 25). For example, if the filestructure is purse, the data is billing data, and the access mode, suchas adding (add) and subtracting (Sub), can be set. Examples of the filestructures, the access modes that can be set, and the commands sent fromthe reader/writer as the device access unit to the device are shown inFIG. 30.

[0542]FIG. 30 illustrates examples of the access modes and the commandswhen the file structure is random, and the access modes and the commandswhen the file structure is a composite file.

[0543] For example, when the file structure is random, and when theaccess mode is Read, the command that can be accepted by the device isonly [Read]. Similarly, when the file structure is random, and when theaccess mode is encryption read, the command that can be accepted by thedevice is only [EncRead].

[0544] When the file structure is a composite file including purse andlog, and when the access mode is money depositing, the command that canbe accepted by the device is only [Deposit]. Similarly, when the filestructure is a composite file including purse and log, and when theaccess mode is money withdrawing, the command that can be accepted bythe device is only [Withdraw], [Make Receipt], or [Read Receipt].

[0545] The above-described deposit command is defined in the permissioncommand (see FIG. 30) corresponding to the money deposit of the fileaccess mode (see FIG. 29); [Deposit] is set in the file access mode ofthe access permission ticket; and a composite file including e-money isdesignated in the file ID. Then, an access permission ticket (SPT) iscreated and is sent from the file access device to the device. In thiscase, deposit billing data is sent together with the deposit command.Then, sequential processing can be performed, such as adding X yen tothe file [Purse] in the composite file, and writing the processingrecord into the file [Log] in the composite file. Details of theseprocessings are described below.

[0546] In addition to the combinations of access modes and commandsshown in FIG. 30, other combinations of access modes and commands can beset according to the mode of the use for the device.

[0547] The device stores the definition data of the commands that can beaccepted for the corresponding files stored in the memory, as a table,such as that shown in FIG. 30. Only when the command input from theaccess unit is the command defined in the definition data, the deviceexecutes the command. The definition data of the commands that can beaccepted for a composite file includes a sequence command consisting ofa plurality of commands to be executed on a plurality of files containedin a composite file.

[0548] A specific file to be processed is set in the file ID of theservice permission ticket (SPT), and a predetermined access mode is setin the file access mode of the service permission ticket (SPT), therebyenabling the control of the file access using the service permissionticket (SPT). The specific processing is discussed below by using aflow.

[0549]FIG. 31 illustrates the data format of the service permissionticket (SPT) of the type in which access is allowed to a plurality offiles among the files set in the partition. The following items of dataare stored in the service permission ticket (SPT):

[0550] Ticket Type: the type of ticket;

[0551] Format Version: the format version of the ticket;

[0552] Ticket Issuer: the identifier of the partition manager (=PMC);

[0553] Serial Number: the serial number of the ticket;

[0554] Size of Ticket: the size of the ticket;

[0555] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket;

[0556] Ticket User Group: the group to which the ticket user belongs;

[0557] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device;

[0558] Ticket User Identifier: ID data (category or identifier) fordetermining the ticket user,

[0559] this field being associated with [Authentication Type] (when[Authentication Type] is the public key authentication, the ID name (DN:Distinguished Name) or the category is stored; when [AuthenticationType] is the common key authentication, the authentication ID is stored;and when authentication is not required, it is not essential that IDdata be stored);

[0560] File ID: the identifiers (IDs) of the access files in thepartition;

[0561] File Access Mode: the access modes of the files to be accessed;

[0562] Group of Target File: the group of files to be accessed;

[0563] Target File ID: the identifiers (IDs) of the files to beaccessed;

[0564] Read/Write Permission: the processing mode (read, write) of thefiles to be accessed (Target File);

[0565] Integrity Check Type: the type of integrity check value of theticket (public key system (Public)/common key system (Common)); and

[0566] Integrity Check Value: the integrity check value of the ticket(public key system: (signature), and common key system: (MAC)).

[0567] By defining the group of files to be accessed and recording it inthe ticket, as described above, a plurality of files in the partitioncan be accessed by a single service permission ticket (SPT).

[0568] When sending the ticket issued by the service permission ticket(SPT) issuing means (SPT Issuer) to the ticket user, the public keycertificate (CERT_SPTI) of the service permission ticket (SPT) issuingmeans (SPT Issuer) is sent together with the ticket when the public keysystem is employed. The attribute of the public key certificate(CERT_SPTI) of the SPT issuing means coincides with the identifier(SPTIC) of the SPT issuing means (SPT Issuer).

[0569] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether the public key system orthe common key system is to be performed, or whether either system is tobe allowed are recorded, though details are described below.

[0570] After verifying the public key certificate (CERT_SPTI) of theservice permission ticket (SPT) issuing means (SPT Issuer), thesignature of the ICV (integrity check value) can be verified by usingthe public key of the service permission ticket (SPT) issuing means (SPTIssuer) extracted from the public key certificate (CERT_SPTI). Theseprocessings are discussed below by using flows.

[0571] (A8.4. Data Update Ticket (DUT))

[0572] The data update ticket (DUT) is the access control ticket usedfor accessing and updating the various data stored in the device. Theticket user (ex. reader/writer as a device access unit) accesses thedevice by using the DUT issued by an authorized data update ticket (DUT)issuing means (Ticket Issuer) according to the procedure recorded in theDUT, thereby making it possible to perform data processing within therestriction recorded in the DUT.

[0573] There are two types of data update tickets (DUTs): a ticketDUT(DEV) used for updating data items managed by the device manager anda ticket DUT(PAR) used for updating data items in the partition managedby the partition manager. The ticket: DUT(DEV) issuing means is underthe management of the device manager, and the ticket: DUT(PAR) is underthe management of the partition manager.

[0574]FIG. 32 illustrates the data formats of the two data updatetickets DUT(DEV) and DUT(PAR). The following data items are stored inthe data update ticket (DUT):

[0575] Ticket Type: the type of ticket (DUT(DEV)/DUT(PAR));

[0576] Format Version: the format version of the ticket;

[0577] Ticket Issuer: the identifier of the device/partition manager (ifthe type of ticket is DUT(DEV), the ticket issuer is DMC, and if thetype of ticket is DUT(PAR), the ticket issuer is PMC);

[0578] Serial Number: the serial number of the ticket;

[0579] Size of Ticket: the size of the ticket;

[0580] Ticket User Group: the group to which the ticket user belongs;

[0581] Ticket User Identifier: the ID data (category or identifier) fordetermining the ticket user;

[0582] this field being associated with [Authentication Type] (when[Authentication Type] is the public key authentication, the ID name (DN:Distinguished Name) or the category is stored; when [AuthenticationType] is the common key authentication, the authentication ID is stored;and when authentication is not required, it is not essential that IDdata be stored);

[0583] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device;

[0584] Encrypted Flag: indicating whether the data to be updated isencrypted (when it is encrypted: Encrypted/when it is not encrypted:none);

[0585] Old Data Code: the code of old data to be updated;

[0586] Data Version Rule: the version conditions when updating the data;

[0587] Data Version Condition: the version value when updating the data;

[0588] Size of New Data: the size of updating new data;

[0589] New Data: updating new data (may be encrypted);

[0590] New Data Version: the version of updating data;

[0591] Integrity Check Type: the type of integrity check value of theticket (public key system (Public)/common key system (Common)); and

[0592] Integrity Check Value: the integrity check value of the ticket(public key system: (signature), and common key system: (MAC)).

[0593] When updating the data using the data update ticket (DUT), theconditions are indicated by a combination of two fields, such as [DataVersion Rule: the version conditions when updating the data] and [DataVersion Condition: the version value when updating the data].

[0594] There are three types of version conditions [Data Version Rule]when updating the data: Any, Exact, and Older.

[0595] “Any” means that data can be updated regardless of the versionconditions.

[0596] “Exact” means that data can be updated when the version value isthe same as the value designated in the subsequent filed [Data VersionCondition].

[0597] “Older” means that data can be updated only when the new dataversion is newer.

[0598] If the version condition [Data Version Rule] is Any or Older,[Data Version Condition] is not used or ignored.

[0599] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether the public key system orthe common key system is to be performed or whether either system is tobe allowed are recorded, though details are described below.

[0600] If the device manager also serves as the data updateticket-DUT(DEV) issuing means (DUT Issuer), the code (ticket user) ofthe data update ticket-DUT(DEV) issuing means (DUT Issuer) can be set asthe device manager code (DMC). If the partition manager also serves asthe data update ticket-DUT(PAR) issuing means (DUT Issuer), the code ofthe data update ticket-DUT(PAR) issuing means (DUT Issuer) can be set asthe partition manager code (PMC).

[0601] In [Authentication Type] in which the type of mutualauthentication (public key authentication, common key authentication, oreither type (Any)) of the device is recorded, the authentication type tobe performed as mutual authentication using the ticket is recorded. Morespecifically, information indicating whether the device authentication,the partition authentication, or both types of authentication are to beperformed, and information indicating whether the public key system orthe common key system is to be performed or whether either system is tobe allowed are recorded, though details are described below.

[0602] In the [Integrity Check Value] field in which the integrity checkvalue (public key system: signature, common key system: MAC) of theticket is recorded, the signature based on the private key of the deviceupdate ticket issuing means (DUT Issuer) is generated (see FIG. 12) andstored if the public key system is employed. If the device manager alsoserves as the device update ticket issuing means (DUT Issuer), thesignature is generated by using the private key of the device manager.If the partition manager also serves as the device update ticket issuingmeans (DUT Issuer), the signature is generated by using the private keyof the partition manager. When performing the signature verificationprocessing (see FIG. 13), the public key of the device manager or thepartition manager is used. Accordingly, it is necessary for the devicewhich performs the ticket verification to obtain the public key (publickey certificate) of the device update ticket issuing means (DUT Issuer)(ex. the device manager or the partition manager) when or beforereceiving the ticket.

[0603] After verifying the public key certificate (CERT_DUTI) of thedevice update ticket (DUT) issuing means (DUT Issuer), the signature ofthe ICV (integrity check value) can be verified by using the public keyof the data update ticket (DUT) issuing means (DUT Issuer) extractedfrom the public key certificate (CERT_DUTI).

[0604] An example of the data to be updated using the data update ticket(DUT) is shown in FIG. 33.

[0605] As shown in FIG. 33, the data to be updated includes the devicemanager code, the device manager code version, the partition managercode, the partition manager code version, the code of each ticketissuing means, the MAC generation key and the version of each ticket,the revocation list, etc. These data items are updated by using the dataupdate ticket (DUT) according to the rules recorded in the DUT. Thespecific procedure of the updating processing is described below byusing a flow. The version information, such as the device manager codeversion and the partition manager code version, is updated when updatingthe data provided with the version. These items of version informationare stored in the data update ticket (DUT).

[B. Detailed Description of Device Distribution to User, VariousSettings for Device, and Device Usage Processing]

[0606] A description is given below, with reference to the flow chartsand other drawings, of the processing performed until the deviceprovided with a memory area having divided partitions is used, anddetails of the device usage processing. A description is given in thefollowing order.

[0607] B1. Flow from Device Initial registration to Usage

[0608] B2. Initial Registration processing by Device ManufacturingEntity

[0609] B3. Device Manager Management Processing

[0610] B3.1. Device Registration processing by Device Manager

[0611] B3.2. Public Key Certificate Issuing Processing under DeviceManager Control

[0612] B4. Partition Manager Management Processing

[0613] B4.1. Partition Setting Registration and Deletion ProcessingUsing Partition Registration Ticket (PRT) under Partition ManagerControl

[0614] B4.2. Public Key Certificate Issuing Processing under PartitionManager Control

[0615] B4.3. File Creation and Deletion Processing Using FileRegistration Ticket (FRT)

[0616] B5. Service (File Access) Processing Using Service PermissionTicket (SPT)

[0617] B6. Device Data Updating Processing Using Data Update Ticket(DUT)

[0618] [B1. Flow from Device Initial Registration to Usage]

[0619] A device having an EEPROM (flash memory) is manufactured by thedevice manufacturing entity (manufacturer), and the initial data iswritten into the device by the device manager. Then, the device isprovided (ex. sold or loaned) to the user and is utilized. For receivingthe services using the device from various service entities by the user,partitions must be set in the device memory by a partition manager, andfiles in which service providing data is stored must be set in thepartitions.

[0620] When performing various processings on the device, such as thepartition setting using the partition registration ticket (PRT), thefile setting using the file registration ticket (FRT), and the dataaccess using the service permission ticket (SPT), various procedures areconducted between the device and the ticket user (ex. reader/writer as adevice access unit) that performs processings on the device. Forexample, the processings on the device include mutual authenticationprocessing for verifying that the device and the ticket user areauthorized devices, signature creation and verification processing forensuring and verifying the integrity of transfer data, and dataencryption and decryption processing. In the configuration of thepresent invention, a public key certificate is employed for performingthese processings. Accordingly, before the use of the services by usingthe device, a public key certificate for the device is issued and isstored in the device.

[0621] For example, various processings, such as the partition settingusing the partition registration ticket (PRT), the file setting usingthe file registration ticket (FRT), and the data access using theservice permission ticket (SPT), are performed on the condition that theintegrity of the device and the ticket user (ex. reader/writer as adevice access unit) performing the processing on the device is verifiedafter performing the mutual authentication between the device and theuser ticket. Also, a digital signature is added to data to betransferred between the device and the user ticket according to thenecessity, and the data is verified. The data to be transferred is alsoencrypted and decrypted according to the necessity.

[0622]FIG. 34 schematically illustrates the flow from the manufacturingof the device to the use of the device. For the understanding of theoverall processing, the individual steps shown in FIG. 34 are brieflydescribed below, though details thereof are given below by using flows.

[0623] 1. The device is manufactured by the device manufacturing entity(manufacturer). When manufacturing the device, the device code is addedto the device as the ID data (ID) of the device. During themanufacturing process, various items of manufacture information(Manufacture Information Block (see FIG. 14)), such as the device codeand the manufacture code, are stored in the device memory.

[0624] 2. Before providing the device to the user, the device managerstores, the device management information (see FIG. 15), such as the IDof the device manager and the public key of the certificate authority(PUB CA(DEV)), and the device key (see FIG. 18), in the memory.

[0625] 3. The device into which the management information is written bythe device manager is provided to the user.

[0626] 4. Then, the user obtains the device public key certificate, andstores the device public key certificate (CERT DEV) into the device keyarea (see FIG. 18) of the device.

[0627] 5. The service entity (partition manager) which is to set apartition in the device memory and provide the services makes apartition setting request to the device manager, receives anacknowledgement and the partition registration ticket (PRT). Thepartition manager also specifies the public key (PUB CA(PAR)) of thecertificate authority used for communicating with the device.

[0628] 6. The device communicates with the ticket user (ex.reader/writer as a device access unit) managed by the partition manager,and performs the partition registration processing by using thepartition registration ticket (PRT), and also stores the public key (PUBCA(PAR)) of the certificate authority in the partition key area (seeFIG. 23).

[0629] 7. The device in which the partition is set sends a request toissue a partition public key certificate to the partition manager, andstores the obtained partition public key certificate (CERT PAR) in thepartition key area (see FIG. 23).

[0630] The partition setting and other processings in theabove-described steps 5 through 7 are performed for each partitionmanager which is to set a partition and provide the services, and aplurality of partitions are registered in the device.

[0631] 8. Then, the partition manager performs the file settingregistration processing corresponding to the services to be provided byusing the file registration ticket (FRT) in the partition set in thedevice.

[0632] 9. 10. By registering files in the set partition, variousservices defined by the file data, such as e-money and a commuterticket, can be provided. Processing, such as data reading and datawriting, can be performed by using the service permission ticket (SPT).That is, the data reading and the data writing can be performedaccording to the rules recorded in the SPT only when the servicepermission ticket (STP) issued by authorized ticket issuing means isemployed.

[0633] Although it is not shown, the data (ex. the device manager code,the device manager code version, the partition manager code, thepartition manager code version, the code of each ticket issuing means,the MAC generation key and its version of each ticket, or the revocationlist) stored in the device is updated by using the data update ticket(DUT) according to the necessity. The version information, such as thedevice manager code version and the partition manager code version, isupdated when updating the corresponding data provided with the version.The version information is stored in the data update ticket (DUT).

[0634] Details of the individual processings are described below withreference to the flows and the other drawings.

[0635] [B2. Initial Registration Processing by Device ManufacturingEntity]

[0636] The initial registration processing by the device manufacturingentity is first described with reference to FIG. 35. The processing of aregistration unit of the device manufacturing entity (Manufacture) isshown at the left side of FIG. 35, and the processing of the device (seeFIG. 5) is shown at the right side of FIG. 35. The registration unit ofthe device manufacturing entity (Manufacture) is configured as thereader/writer (see FIG. 10), which serves as a dedicated device accessunit for reading and writing data from and into the device.

[0637] In step S101, the registration unit sends a read command for awritable flag of the manufacture information block (MIB (see FIG. 14))to the device. Upon receiving the command (S121), the device sends thewritable flag in the manufacture information block of the device memory(S122).

[0638] Upon receiving the writable flag in the manufacture informationblock (MIB) (S102), the registration unit determines whether thewritable flag is set to write enable (0xffff) (S103). If the writableflag is not set to write enable (0xffff), the subsequent writingprocessing for the manufacture information block (MIB) cannot beexecuted, and the process is terminated as an error.

[0639] If the writable flag is set to write enable (0xffff), themanufacture information block (MIB) (see FIG. 14) of the device isgenerated (S104), and MIB data is sent to the device together with anMIB write command (S105).

[0640] Upon receiving the MIB write command and the MIB data (S123), thedevice verifies the integrity of the MIB writable flag (S124). If thewritable flag is not set to write enable (0xffff), the subsequentwriting processing for the manufacture information block (MIB) cannot beexecuted, and the process is terminated as an error. If the writableflag is set to write enable (0xffff), the received MIB data is writteninto the MIB area (S125).

[0641] Upon completing the MIB data writing processing, a write completemessage is sent to the registration unit (S126). Upon receiving thewrite complete message (S106), the registration unit sends an initialregistration completion command to the device (S107). Upon receiving theinitial registration completion command (S127), the device sets thewritable flag of the manufacture information block (MIB) to writedisable (0x0000) (S128), and sends a write completion message to theregistration unit (S129).

[0642] Upon receiving the write completion message (S108), theregistration unit sends a read command for the writable flag of themanufacture information block (MIB) (see FIG. 14) to the device (S109).Upon receiving the command (S130), the device sends the writable flag inthe manufacture information block (MIB) of the device memory to theregistration unit (S131).

[0643] Upon receiving the writable flag in the manufacture informationblock (MIB) (S110), the registration unit determines whether thewritable flag is set to write disable (0x0000) (S111). If the writableflag is not set to write disable (0x0000), it means that the MIB datawriting processing has not been successfully finished, and the processis terminated as an error. If the writable flag is set to write disable(0x0000), it means that the MIB data writing processing has beensuccessfully finished, and the process is completed.

[0644] [B3. Device Manager Management Processing]

[0645] The management processing of the device manager is as follows.The processing to be executed before the start of the use of the deviceis discussed. The processing to be executed by the device manager beforethe start of the use of the device includes the device registrationprocessing and the issuing processing of the device public keycertificate (CERT DEV) for the device. The device registrationprocessing is executed as writing data into the device managementinformation block (DMIB), the public-key device key definition block(DKDB(PUB)), the common-key device key definition block (DKDB(Common)),and the device key area of the device memory. Details of the processingsare described below.

[0646] [B3.1. Device Registration Processing by Device Manager]

[0647] A description is given below, with reference to the flow of FIG.36, of the initial registration processing accompanied by the storing ofthe device management information and other information in the device bythe device manager. In the flows of FIG. 36 and the subsequent drawings,the processing of the initial registration unit of the device manager(DM) is shown at the left side, and the processing of the device (seeFIG. 5) is shown at the right side. The initial registration unit of thedevice manager (DM) is a unit that can read and write data from and intothe device (ex. a reader/writer or a PC as a device access unit), andhas the configuration of a reader/writer as a device access unit, suchas that shown in FIG. 10.

[0648] First, in step S201, a read command for the device identifier IDmis output to the device. The device receives the command (S211), andsends the device identifier IDm to the registration unit (S212).

[0649] Upon receiving the device identifier IDm (S202), the registrationunit sends a read command for the writable flag of the device managementinformation block (DMIB (see FIG. 15)) to the device (step S203). Thedevice receives the command (S213), and sends the writable flag in thedevice management information block (DMIB) of the device memory to theregistration unit (S214).

[0650] Upon receiving the writable flag in the device managementinformation block (DMIB) (S204), the registration unit determineswhether the writable flag is set to write enable (0xffff) (S205). If thewritable flag is not set to write enable (0xffff), the subsequentwriting processing for the device management information block (DMIB)cannot be executed, and the process is terminated as an error.

[0651] If the writable flag is set to write enable (0xffff), a write(DMC Write) command containing a device manager code (DMC) and DMCversion is sent to the device (S206). This code is preassigned to thedevice manager by the code management institution (see FIGS. 1 through3).

[0652] Upon receiving the DMC Write command (S215), the device verifiesthe DMIB writable flag (S216). If the writable flag is not set to writeenable (0xffff), the subsequent writing processing for the devicemanagement information block (DMIB) cannot be executed, and the processis terminated as an error. If the writable flag is set to write enable(0xffff), the received device manager code (DMC) and the DMC version arewritten into the DMIB area (S217).

[0653] Upon completing the writing of the device manager code (DMC) andthe DMC version, the write completion message is sent to theregistration unit (S218). The registration unit receives the writecompletion message (S207), and then sends a device-total-block-numberwrite command to the device (S208).

[0654] Upon receiving the device-total-block-number write command(S219), the device verifies the DMIB writable flag (S220). If thewritable flag is not set to write enable (0xffff), the subsequentwriting processing for the device management information block (DMIB)cannot be executed, and the process is terminated as an error. If thewritable flag is set to write enable (0xffff), the received device totalblock number is written into the DMIB area (S221). The device alsowrites TB-4 into the free block number in device of the DMIB area(S222). TB indicates the device total block number. The four blocks ofTB-4 indicate the manufacture information block (MIB), the devicemanagement information block (DMIB), the public-key device keydefinition block (DKDB(PUB)), and the common-key device key definitionblock (DKDB(Common)).

[0655] Then, the device writes 0 into the partition number area of thedevice management information block (DMTB) (S223) since partitions arenot set in the device at this point. The device also writes 0 into thepointer of free area of DMIB (S224), and sends the writing processingcompletion to the registration unit (S225).

[0656] The registration unit receives the writing processing completionmessage from the device (S209), and then determines whether a common keyis used for device authentication (S231). For the authenticationprocessing, either a public key authentication system or a common keyauthentication system is employed, and details thereof are given below.The device manager is able to set the authentication system required forthe device. If the device executes the common key authentication, thedevice manager sets the information required for the common keyauthentication (ex. master key for creating an authentication key) inthe device. If the device does not execute the common keyauthentication, the device manager does not set the above information inthe device. The device manager sets data for implementing either thecommon key authentication or the public key authentication, or bothtypes of authentication in the device according to the authenticationsystem employed in the device.

[0657] As shown in FIG. 37, if the common key is used for deviceauthentication, steps S232 and S233, and steps S241 through S245 areexecuted, and if the common key is not used for device authentication,these steps are skipped.

[0658] If the common key is used for device authentication, in stepS232, the registration unit sends a common-key authentication data writecommand, such as MKauth_DEV_A: the two-way individual key authenticationmaster key, Kauth_DEV_B: the two-way individual key authenticationcommon key, IRL_DEV: the revocation list in which the device identifiers(IDs) of revoked devices are registered, and the version informationthereof, to the device.

[0659] The device receives the above-described write command in stepS241, and after checking that the DMIB writable flag is write enable instep S242, the device writes the received data into the device key area(see FIG. 18) (S243). Then, the device makes adjustments of the pointer,the size, and the free block number in device, which are required due tothe data writing (S244), and sends a write completion message to theregistration unit (S245).

[0660] Upon receiving the write completion message (S233), theregistration unit determines in step S234 whether a public key is to beemployed for device authentication. As shown in FIG. 37, if a public keyis employed for device authentication, steps S235 through S239 and stepsS246 through S254 are executed. If a public key is not employed fordevice authentication, these steps are skipped.

[0661] If the public key is employed for device authentication, in stepS235, the registration unit sends a public-key authentication data writecommand, such as PUB_CA(DEV): the public key of the certificateauthority CA(DEV) that issues the device-manager public key, PARAM_DEV:the public key parameter of the device, CRL_DEV: the revocation list(Revocation List Certificate) in which the public key certificateidentifiers (ex. serial number: SN) of the revoked devices areregistered, and the version information thereof, to the device.

[0662] The device receives the above-described write command in stepS246, and after checking that the DMIB writable flag is write enable instep S247, the device writes the received data into the device key area(see FIG. 18) (S248). Then, the device makes adjustments of the pointer,the size, and the free block number in device, which are required due tothe data writing (S249), and sends a write completion message to theregistration unit (S250).

[0663] Upon receiving the write completion message (S236), theregistration device sends a key-pair creation command for creating apublic key and a private key to the device (S237). Although in thisembodiment the device creates a key pair, the registration unit, forexample, may create a key pair, and provides it to the device.

[0664] Upon receiving the key-pair creation command (S251), the devicecreates a key pair of the public key (PUB DEV) and the private key (PRIDEV) in the encryption processor (see FIG. 5) of the device, and writesthe created key into the device key area (see FIG. 18) (S252). Thepublic key (PUB DEV) is temporarily stored in the CERT DEV area of thedevice key area, and when the public key certificate in which the publickey (PUB DEV) is stored is received, the public key (PUB DEV) issubstituted by the public key certificate (CERT). The device then makesadjustments of the pointer, the size, and the free block number indevice, which are required due to the data writing (S253), and sends thegenerated and stored public key to the registration unit (S254).

[0665] The registration unit receives the public key (PUB DEV) from thedevice, and stores it in the database (DB(DEV) (see FIG. 7)) in thedevice manager, together with the device identifier IDm previouslyreceived from the device.

[0666] Then, the registration unit of the device manager determineswhether a common key is to be used for verifying the partitionregistration ticket (PRT) (S261). For verifying the ticket, either acommon key system to verify the ticket with a MAC value or a public keysystem to generate a signature by using a private key and to verify thesignature by using a public key, which has been discussed with referenceto FIGS. 12 and 13, can be employed. Details of ticket verification arediscussed below. The device manager is able to set the verificationprocessing method to be used in the device. The device manager sets datafor implementing a common key system or a public key system, or bothtypes, according to the PRT ticket verifying method used in the device.

[0667] If the device is able to execute common key authentication, thedevice manager sets information required for common-key PRT verification(ex. PRT verification common key) in the device. If the device does notexecute common key authentication, the device manager does not storesuch information in the device.

[0668] As shown in FIG. 38, if the common key system is used for PRTverification, steps S262 and S263 and steps S271 through S275 areexecuted. If the common key is not used for PRT verification, thesesteps are skipped.

[0669] When the common key is employed for PRT verification, in stepS262, the registration unit sends a PRT-verification common key writecommand, such as Kprt: the MAC checking key of the partitionregistration ticket (PRT) and the version information, to the device.

[0670] The device receives the above-described write command in stepS271, and after checking in step S272 that the DMIB writable flag iswrite enable, the device writes the received data into the device keyarea (see FIG. 18) (S273). Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing (S274), and sends a write completionmessage to the registration unit (S275).

[0671] Upon receiving the write completion message (S263), theregistration unit determines in step S264 whether a public key is to beused for PRT verification. As shown in FIG. 38, if a public key is usedfor PRT verification, steps S265 and S266 and steps S276 through S282are executed. If a public key is not used for PRT verification, thesesteps are skipped.

[0672] If the public key is employed from PRT verification, in stepS265, the registration unit sends a PRT-verification data write command,such as PRTIC (PRT Issuer Category): the partition registration ticket(PRT) category, PUB_CA(DEV): the public key of the certificate authorityCA(DEV) that issues the device-manager public key, PARAM_DEV: the publickey parameter of the device, CRL_DEV: the revocation list (RevocationList (Certificate)) in which the public key certificate identifiers (ex.serial number: SN) of revoked devices are registered, and the versioninformation thereof, to the device.

[0673] The device receives the above-described write command in stepS276, and after checking that the DMIB writable flag is write enable instep S277, the device writes PRTIC (PRT Issuer Category): the partitionregistration ticket (PRT) issuer category in the received data into thepublic-key device key definition block (DKDB(PUB)) (see FIG. 16), andwrites the version information into the version area of the same blockin step S278.

[0674] Then, the device determines in step S279 whether PUB_CA(DEV): thepublic key data of the certificate authority CA(DEV) that issues thedevice-manager public key has been written. If PUB_CA(DEV) has not beenwritten, in step S280, the device writes PUB_CA(DEV), PARAM_DEV, andCRL_DEV into the device key area (see FIG. 18). Then, the device makesadjustments of the pointer, the size, and the free block number indevice, which are required due to the data writing (S281), and sends awrite completion message to the registration unit (S282).

[0675] Upon receiving the write completion message (S266), theregistration unit determines in step S291 whether the device is a devicewhich supports the updating of the common key data. Among the data itemsstored in the device, there are items that can be updated by using theabove-described data update ticket (DUT) (see FIG. 32). The data itemsto be updated have been discussed above with reference to FIG. 33. Forthe updating processing using the data update ticket (DUT), either acommon key system or a public key cryptosystem can be employed. Thedevice manager sets data for implementing either type or data forimplementing both types according to the device.

[0676] If the device is a device that performs data updating by a commonkey system, the device manager sets information required for the dataupdating using the common key system (ex. MAC checking key of the dataupdate ticket (DUT)) in the device. If the device does not execute thecommon key authentication, the device manager does not set suchinformation in the device.

[0677] As shown in FIG. 39, if the common key system is employed fordata updating by using the data update ticket (DUT), steps S292 and S293and steps S301 through S305 are executed. If the common key system isnot employed for data updating, these steps are skipped.

[0678] If the common key is used for data updating, in step S292, theregistration unit sends a data update ticket (DUT)-verification commonkey write command, such as Kdut_DEV1: the MAC checking key of the dataupdate ticket (DUT), Kdut_DEV2: the data updating encryption key,Kdut_DEV3: the MAC checking key of the data update ticket (DUT), andKdut_DEV4: the data updating encryption key, and the version informationthereof, to the device.

[0679] In step S301, the device receives the above-described writecommand, and after determining that the DMIB writable flag is writeenable in step S302, the device writes the received data into the devicekey area (see FIG. 18) (S303). Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing (S304), and sends a write completionmessage to the registration unit (S305).

[0680] Upon receiving the write completion message (S293), theregistration unit determines in step S294 whether the device supportsthe data updating using the data update ticket (DUT) according to thepublic key system. As showh in FIG. 39, if the device supports thepublic key system, steps S295 and S296 and steps S306 through S310 areexecuted. If the device does not support the public key system, thesesteps are skipped.

[0681] If the device supports the public key system, in step S295, theregistration unit sends a data update ticket (DUT) issuer code writecommand, such as DUTIC_DEV (DUT Issuer Category): the data update ticket(DUT) issuer category and the version information, to the device.

[0682] In step S306, the device receives the above-described writecommand, and after checking that the DMIB writable flag is write enablein step S307, in step S308, the device writes the received data into thepublic-key device key definition block (DKDB(PUB)) (S308). Then, thedevice makes adjustment of the pointer, the size, and the free blocknumber in device, which are required due to the data writing (S309), andsends a write completion message to the registration unit (S310).

[0683] Upon receiving the write completion message (S296), theregistration unit sends a device manager (DM) initial registrationcompletion command to the device in step S321. Upon receiving thecommand (S331), the device determines in step S332 whether data forimplementing at least one of the public key system and the common keysystem has been set for each of the mutual authentication, theverification of the partition registration ticket (PRT), and theverification of the data update ticket (DUT). If the data isinsufficient, the processings cannot be completely performed. Then, theinitial registration by the device manager is determined to be an error,and the process is terminated.

[0684] If it is found in step S332 that the data for implementing atleast one of the public key system and the common key system has beenset for each of the mutual authentication, the verification of thepartition registration ticket (PRT), and the verification of the dataupdate ticket (DUT), in step S333, the device sets the writable flag ofthe device management information block (DMIB) to write disable(0x0000), and sends a write completion message to the registration unit(S334).

[0685] Upon receiving the write completion message (S322), theregistration unit sends a read command for the writable flag of thedevice management information block (DMIB) (see FIG. 15) to the device(S323). The device receives the command (S335), and then sends thewritable flag in the device management information block (DMIB) of thedevice memory (S336).

[0686] Upon receiving the writable flag in the device managementinformation block (DMIB) (S324), the registration unit determineswhether the writable flag is set to write disable (0x0000). If thewritable flag is not set to write disable (0x0000), it means that theDMIB data writing processing has not been successfully finished, and theprocess is terminated as an error. If the writable flag is set to writedisable (0x0000), it means that the DMIB data writing processing hasbeen successfully finished, and the process is completed.

[0687]FIG. 41 illustrates an example of the data stored in the memorydevice in the state in which the initial registration by the devicemanufacturing entity (Manufacture) (the processing flow in FIG. 35) andthe initial registration processing by the device manager (theprocessing flows from FIGS. 36 to 40) are completed. FIG. 41 illustratesthe manufacture information block, the device management informationblock, the public-key device key definition block (PUB), the common-keydevice key definition block (Common), and the device key area, which arediscussed with reference to FIGS. 6, 14 through 18. At this point,partitions are not formed in the memory.

[0688] The device code and other information are written into themanufacture information block as the device unique information, asdiscussed with reference to FIG. 14. The information or part of theinformation written into the manufacture information block, orcomputation data obtained based on the written information, correspondsto the device identifier (IDm).

[0689] In the device key area shown in FIG. 41, Kauth_DEV_B: the two-wayindividual key authentication common key, and MKauth_DEV_A: the two-wayindividual key authentication master key are stored. However, these keysdo not have to be stored if the device does not receive a request toperform common key authentication processing. Also, Kprt: the MACchecking key of the partition registration ticket (PRT) does not have tobe stored if the device does not perform the ticket checking processingusing the common key.

[0690] Moreover, IRL_DEV: the revocation list (Revocation List (DeviceID)) in which the device identifiers (IDs) of the revoked devices areregistered, and CRL_DEV: the revocation list (Revocation List(Certificate)) in which the public key certificate identifiers (ex.serial number: SN) of the revoked devices are registered do not have tobe stored if there is no revoked device when the device is issued, or ifthe revocation lists are obtained by another source.

[0691] [B3.2. Public Key Certificate Issuing Processing under DeviceManager Control]

[0692] The processing for issuing a device public key certificate by thedevice manager is described below with reference to FIG. 42 and thesubsequent drawings. In the device, the device public key certificate(CERT DEV) used for authenticating the entire device and for performingprocessing based on the device, and the partition public key certificate(CERT PAR) used for authentication and verification when performing theprocessing on a specific partition in the device are stored. Thepartition public key certificate (CERT PAR) can be stored in eachpartition set in the device.

[0693] The device public key certificate (CERT DEV) is stored in thedevice key area (see FIG. 18), which is the memory area managed by thedevice manager, and the partition public key certificate (CERT PAR) isstored in the partition key area (see FIG. 23), which is the memory areamanaged by each partition manager.

[0694] The device public key certificate (CERT DEV) is issued by aprocedure for providing the public key certificate issued by thecertificate authority (CA for DM) (see FIGS. 2 and 3) via theregistration authority managed by the device manager, and the database222 (see FIG. 7) storing the public key certificate (CERT DEV) issued bythe registration authority managed by the device manager is managed.

[0695] The partition public key certificate (CERT PAR) is issued by aprocedure for providing the public key certificate issued by thecertificate authority (CA for PM) (see FIGS. 2 and 3) via theregistration authority managed by the partition manager, and thedatabase 332 (see FIG. 9) storing the public key certificate (CERT PAR)issued by the registration authority managed by the partition manager ismanaged.

[0696] A description is now given, with reference to FIGS. 42 and 43, ofa procedure for issuing the device public key certificate (CERT DEV) tothe device by the registration authority managed by the device manager.The relationship among the issuing unit (DM) (only the configuration ofthe registration authority (RA) of the device manager is shown), thecertificate authority (CA), and the user device is shown in FIG. 44. Asshown in FIG. 44, the control means 221 contains encryption processingmeans. The encryption processing is performed by executing theencryption processing program under the control of the controller (CPU(2111 in FIG. 8)).

[0697] In FIGS. 42 and 43, the processing of the CERT (public keycertificate) issuing unit of the registration authority managed by thedevice manager, and more specifically, the processing of the controlmeans 221 of the device manager shown in FIG. 7, is shown at the leftside, and the processing of the device is shown at the right side.

[0698] In step S351, the CERT issuing unit obtains user information ofthe device for which the device public key certificate (CERT DEV) is tobe issued, permits (determines) the issuing of the certificate, andensures a communication channel with the device. The user information ofthe device for which the device public key certificate (CERT DEV) is tobe issued can be obtained by, for example, the data generated when thedevice initial registration is performed. Alternatively, the user name,the user address, the telephone number, the e-mail address, etc. may beseparately obtained by another source. The user information may beobtained from the device after the communication channel with the deviceis set. The communication channel may be a cable or wirelesscommunication channel through which data can be sent and received.

[0699] Then, in step S352, the CERT issuing unit sends anauthentication-data creation command containing a random number to thedevice. Upon receiving the authentication-data creation command (S361),the device executes the digital-signature (S) generating processing (seeFIG. 12) by applying the device private key (PRI DEV) to the couplingdata of the received random number R and the device identifier (IDm)(S362). The device sends the device ID data (ID) and the signature (S)to the CERT issuing unit.

[0700] Upon receiving the ID data (IDm) and the signature (S) from thedevice (S353), the CERT issuing unit obtains the device public key (PUBDEV) stored in the database DB(DEV) 222 by using the received device IDdata (IDm) as a search key. The CERT issuing unit then executes thesignature (S) verification processing (see FIG. 13) by applying theobtained device public key (PUB DEV) (S355). If the signature (S) hasnot been successfully verified, it is determined that the data sent fromthe device is unauthorized data, and the process is terminated.

[0701] If the signature (S) has been successfully verified, the CERTissuing unit requests the certificate authority (CA for DM) 610 toperform the issuing processing of the device public key certificate(CERT DEV) (S357). The device manager receives the device public keycertificate (CERT DEV) issued by the certificate authority 610 (S358),and sends it to the device (S359).

[0702] Upon receiving the device public key certificate (CERT DEV) fromthe device manager (registration authority), the device verifies thesignature of the received device public key certificate (CERT DEV) byusing the public key (PUB CA(DEV)) of the certificate authority that isprestored in the device key area. That is, the public key certificate isprovided with a signature created by the private key of the certificateauthority (see FIG. 11), and this signature is verified (S366).

[0703] If the signature verification has failed, it is determined thatthe public key certificate is not an authorized certificate, and anerror message is sent to the CERT issuing unit (S385).

[0704] If the signature verification has succeeded, the device comparesthe device public key (PUB DEV) stored in the device public keycertificate (CERT DEV) with the device public key (PUB DEV) stored inthe device (S382). If the two keys do not coincide with each other, anerror message is sent, and if the two keys coincide with each other, thedevice public key certificate (CERT DEV) is stored in the device keyarea (see FIG. 18) (S383). Before the issuing of the device public keycertificate (CERT DEV), the public key (PUB DEV) created by the deviceis stored in this area, and when the authorized device public keycertificate (CERT DEV) is issued, the public key (PUB DEV) isoverwritten by the device public key certificate (CERT DEV).

[0705] Upon completion of the storage of the device public keycertificate (CERT DEV), the device sends a storage completion message tothe CERT issuing unit (S384). The CERT issuing unit receives the storagecompletion message (S371), and determines whether the storage processinghas been successfully finished (S372). The CERT issuing unit thencompletes the process. If it cannot be determined that the storageprocessing has been successfully finished, the process is terminated asan error.

[0706]FIG. 45 illustrates the data sending and receiving processingamong the entities, such as the device manager 200, the device 100, andthe certificate authority (CA) 610, when performing the processing forissuing the device public key certificate (CERT DEV).

[0707] The processing is executed in the order of Nos. 1 to 14 in FIG.45. Process No. 1 in which the device manager 200 obtains the deviceidentifier (IDm) and the device public key (PUB DEV) from the device 100and process No. 2 in which the device identifier (IDm) is registered areexecuted in the initial registration by the device manager.

[0708] The procedure for issuing the device public key certificate (CERTDEV) starts from process No. 3. 3. The device manager obtains the clientinformation from the device. 4. The client information is registered(which is not necessary if the client information is alreadyregistered). 5. The device identifier (IDm) is obtained from the device.6. The corresponding public key (PUB DEV) is obtained by searching thedatabase based on the obtained device identifier (IDm). 7.Authentication processing between the device and the device manager isperformed. This processing is omitted in the processing shown in FIGS.42 and 43. In FIGS. 42 and 43, since the signature is verified whenobtaining the device identifier (IDm) from the device, theauthentication is omitted by checking the data sent and received betweenthe issuing unit and the device. Either the signature verification inFIGS. 42 and 43 or the authentication in FIG. 45, or both processingsare desirably performed. Details of the authentication processing arediscussed below in Section B.4. Partition Manager Management Processing.

[0709]8. A request to issue the device public key certificate is madefrom the device manager to the certificate authority. 9. The devicepublic key certificate (CERT DEV) is generated. 10. Data of thegenerated public key certificate is registered by the certificateauthority (CA). 11. The public key certificate is distributed from thecertificate authority (CA) 610 to the device manager 200. 12. Thedatabase of the device manager is updated (registering thepublic-key-certificate issued information). 13. The device public keycertificate (CERT DEV) is sent from the device manager to the device.14. The device public key certificate (CERT DEV) is stored in thedevice: it is stored in the device key area, as discussed above.

[0710] According to the above-described processing, the device obtainsthe device public key certificate (CERT DEV) and stores it in thememory. The data storage configuration of the individual blocks of thememory after the device public key certificate (CERT DEV) is stored inthe device key storage area of the memory is shown in FIG. 46. FIG. 46illustrates the manufacture information block, the device managementinformation block, the public-key device key definition block (PUB), thecommon-key device key definition block (Common), and the device keyarea, which have been discussed with reference to FIGS. 6, 14 through18. At this point, partitions are not formed in the memory.

[0711] In the device key area shown in FIG. 46, the device public keycertificate (CERT DEV) is stored. Before the issuing of the devicepublic key certificate (CERT DEV), the public key (PUB DEV) created bythe device is stored in this area, and upon receiving the device publickey certificate (CERT DEV), the public key (PUB DEV) is overwritten bythe device public key certificate (CERT DEV). If it is necessary tochange the pointer, the size, and the management data b this updatingprocessing, they are also updated.

[0712] [B4. Partition Manager Management Processing]

[0713] The partition manager management processing is described below.The processing to be executed before the start of the use of the deviceis discussed. The processing to be executed before the start of the useof the device includes the setting of partitions in the device memoryand the issuing of the partition public key certificate (CERT PAR) tothe device. Details of these processings are as follows. The partitionsetting processing includes mutual authentication processing (deviceauthentication or partition authentication) between the device and thepartition manager, and the processing for verifying the integrity of thepartition registration ticket (PRT). Basically, the partition deletionprocessing can be executed according to a procedure similar to thepartition creation. Accordingly, the partition deletion processing isalso discussed below together with the partition creation processing.

[0714] [B4.1. Partition Setting Registration and Deletion ProcessingUsing Partition Registration Ticket (PRT) under Partition ManagerControl]

[0715] A description is first given of the partition settingregistration and deletion processing using the partition registrationticket (PRT) (see FIG. 26) with reference to the flow of FIG. 47 andother drawings. As discussed above, the partition setting processingincludes the mutual authentication processing (device authentication orpartition authentication) between the device and the partition manager,and the verification processing for the integrity of the partitionregistration ticket (PRT). These processings are also discussed.

[0716] The partition setting registration processing and deletionprocessing flow shown in FIG. 47 is described below. In FIG. 47, theprocessing of a partition creation/deletion unit of the partitionmanager is shown at the left side, and the processing of the device (seeFIG. 5) is shown at the right side. The partition creation/deletion unitof the partition manager is a unit that can read and write data from andinto the device (ex. a reader/writer or a PC as a device access unit),and corresponds to the reader/writer shown in FIG. 10, which serves asthe device access unit. An overview of the partition creation/deletionprocessing is first discussed with reference to FIG. 47, and details ofthe individual processings included in the partition creation/deletionprocessing are sequentially discussed with reference to the flows ofFIG. 48 and the subsequent drawings.

[0717] First, in steps S401 and S410 of FIG. 47, the mutualauthentication processing is performed between the partitioncreation/deletion unit and the device. Between the two means forperforming data sending and receiving, it is first checked with eachother whether they are authorized data communication means, and then,data transfer is performed according to the necessity. The mutualauthentication processing is to check whether the other party isauthorized data communication means. In one of the preferable datatransfer methods in the mutual authentication processing, a session keyis created, and data is encrypted by using the session key as the commonkey. Then, the data is transferred.

[0718] In the mutual authentication processing in the system of thepresent invention, device authentication or partition authentication isperformed. A common key system or a public key system is used for thedevice authentication or the partition key authentication, which isdiscussed below.

[0719] The processing to be executed as the mutual authenticationprocessing is determined by:

[0720] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket; and

[0721] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device; of the partition registration ticket (PRT) (see FIG. 26) tobe used.

[0722] If the authentication processing has failed (No in steps S402 andS411), it means that it cannot be verified that the two means areauthorized device and unit. Accordingly, the subsequent processing isnot executed, and the process is terminated as an error.

[0723] If the authentication processing has succeeded, the partitioncreation/deletion unit sends the partition registration ticket (PRT) tothe device. The partition registration ticket (PRT) is the ticket issuedby the partition registration ticket (PRT) issuing means (PRT Issuer)managed by the device manager to the partition manager in response to arequest from the partition manager. The partition registration ticket(PRT) is the access control ticket for the device, and has theabove-described data format configuration shown in FIG. 26.

[0724] When the partition registration ticket (PRT) is sent to theticket user, the public key certificate (CERT_PRTI) of the partitionregistration ticket (PRT) issuing means (PRT Issuer) is sent together ifthe public key system is employed. The attribute of the public keycertificate (CERT_PRTI) of the PRT issuing means coincides with theidentifier (PRTIC) of the partition registration ticket (PRT) issuingmeans (PRT User).

[0725] Upon receiving the partition registration ticket (PRT) (S412),the device verifies the integrity of the ticket and also checks the user(S413). The integrity verification processing of the ticket is performedby using the MAC checking of the common key system or the signatureverification processing of the public key system. The user checking isperformed by verifying the integrity of the entity (ticket user) thathas sent the ticket, and, after the mutual authentication has succeeded,it is determined whether the ID data of the entity and the ticket useridentifier (see FIG. 26) recorded in the ticket coincide with eachother. These processings are discussed in detail below.

[0726] In the device, if the integrity of the received ticket (PRT) andthe authenticity of the user cannot be successfully verified (No inS414), a partition registration ticket (PRT) reception error is reportedto the partition creation/deletion unit (S418). If the integrity of theticket and the authenticity of the user are verified (Yes in S414), apartition is created or deleted in the device memory according to therules indicated in the received partition registration ticket (PRT).Details of this processing are also discussed below by using a differentflow.

[0727] If the partition creation/deletion processing has succeededaccording to the description of the partition registration ticket (PRT)(Yes in S416), it is reported to the partition creation/deletion unitthat the PRT reception has succeeded (S417). If the partitioncreation/deletion processing has failed (No in S416), a PRT receptionerror is reported to the partition creation/deletion unit (S418).

[0728] The partition creation/deletion unit receives the PRT receptionresult (S404), and identifies the PRT processing result. If the PRTreception result indicates an error (No in S405), the process isterminated as an error. If the PRT reception result indicates a success(Yes in S405), and if the processing is the partition creationprocessing, the partition initial data is written (S406, S419). Detailsof the writing processing of the initial data are described below byusing a different flow. If the partition initial data has been written,and if the PRT reception result indicates a success (Yes in S405) and ifthe processing is the partition deletion processing, a session clearcommand is sent and received (S407, S420). Then, the authenticationtable created in the device is discarded (S421), and the process iscompleted. The authentication table is created for the mutualauthentication processing in steps S401 and S410 and details arediscussed below.

[0729] As discussed above, by using the partition registration ticket(PRT), a new partition is created in the device or the created partitionis deleted from the device. The mutual authentication processing (S401,S410), the ticket verification and user checking (S413), the partitioncreation and deletion processing (S415), and the partition initial datawriting processing (S406, S419) included in the processing shown in FIG.47 are described in detail below.

[0730] (Mutual Authentication Processing)

[0731] The mutual authentication processing executed in steps S401 andS410 in FIG. 47 is discussed below. The subsequent mutual authenticationprocessing can also be performed in the device access processing using adifferent ticket, such, as the file registration ticket (FRT), theservice permission ticket (SPT), or the data update ticket (DUT) ifnecessary.

[0732] The flow of the mutual authentication processing is shown in FIG.48. In FIG. 48, the processing of the authentication unit of thepartition manager is shown at the left side, and the processing of thedevice (see FIG. 5) is shown at the right side. The authentication unitof the partition manager is a unit that can read and write data from andinto the device (ex. a reader/writer or a PC as a device access unit),and has the configuration of a reader/writer, such as that shown in FIG.10.

[0733] In step S431 of FIG. 48, the authentication unit reads anddetermines the authentication type required for using the partitionregistration ticket (PRT) from the ticket. The authentication mode isnot restricted to the authentication type indicated in the ticket, andthe device authentication or the partition authentication may bedetermined according to the type specified by the access unit (ex.reader/writer).

[0734] The determined authentication type is indicated by A(1) throughA(n). Various authentication processing modes can be set in thepartition setting registration or deletion processing using thepartition registration ticket (PRT). For example, for the partitionregistration setting, device, authentication is required for the device.For the partition deletion, both the device authentication and thepartition authentication, which is for the partition to be deleted, arerequired. Accordingly, it is possible to indicate that eitherauthentication type is required or both authentication types arerequired in the partition registration ticket (PRT) according to theprocessing. The authentication type required for using the PRT isindicated in [Authentication Type] of the partition registration ticket(PRT), and the authentication unit reads and determines theauthentication type required for using the partition registration ticket(PRT) from the ticket, and defines the authentication processingprocedure as A(i): A (1) through A(n).

[0735] In step S432, the authentication unit reads the firstauthentication processing type A(1), and determines whether theauthentication type A(1) is device authentication or partitionauthentication (S433). If it is device authentication, deviceauthentication is executed (S434, S441). If it is partitionauthentication, partition authentication is executed (S435, S442). Ifauthentication has not succeeded after performing authenticationprocessing with the device, the process is terminated as an error. Ifauthentication has succeeded, i is incremented in step S437, and theprocess returns to step S433. Then, the subsequent authentication typeis determined and authentication is executed according to theauthentication type. Such processing is executed from A(1) through A(n),and when all the authentications have succeeded, the process proceeds tothe subsequent step.

[0736] The device authentication processing is described below withreference to the flow of FIG. 49. In FIG. 49, the processing of a deviceauthentication unit of the partition manager is shown at the left side,and the processing of the device (see FIG. 5) is shown at the rightside. The device authentication unit of the partition manager is a unitthat can read and write data from and into the device (ex. areader/writer or a PC as the device access unit), and has theconfiguration of a reader/writer, such as that shown in FIG. 10, whichserves as the device access unit.

[0737] In step S451, the device authentication unit determines based onthe partition registration ticket (PRT) whether a public key systemusing a public key is to be employed for the device authenticationprocessing. The device authentication is performed by either the publickey system or the common key system, and the execution type is indicatedin the ticket.

[0738] If the common key system is specified, steps S452 through S455,and steps S461 through S465 of FIG. 49 are not executed, and the processproceeds to step S456. If the public key system is specified, the deviceauthentication unit sends a public-key device authentication startcommand to the device in step S452. Upon receiving the command (S461),the device determines whether the device public key certificate (CERTDEV) is stored by referring to the public-key device key definitionblock (see FIG. 16) of the device memory (S462). If the device publickey certificate (CERT DEV) is not stored, the mutual authentication ofthe public key system cannot be executed, and the process is terminatedas an error.

[0739] If it is determined that the device public key certificate (CERTDEV) is stored, in steps S453 and S463, the mutual authentication andkey sharing processing is performed by using the public key certificateissued by the device-manager certificate authority (CA(DEV)).

[0740] The mutual authentication and key sharing using the public keysystem is described below with reference to FIG. 50. FIG. 50 illustratesthe mutual authentication sequence using a 160-bit-length elliptic curvecryptosystem (ECC), which is a public key cryptosystem. Although in FIG.50 ECC is used as the public key cryptosystem, another type of publickey cryptosystem may be employed. Also, the key size does not have to be160 bits. In FIG. 50, B generates a 64-bit random number Rb, and sendsit to A. A receives the random number Rb and generates a new 64-bitrandom number Ra and a new random number Ak, which is smaller than thecharacteristic p. Then, the point Av is calculated by multiplying thebase point G by Ak (Av=Ak×G), and the digital signature A. Sig for theRa, Rb, and Av (X coordinate and Y coordinate) is generated. A thensends the digital signature A. Sig to B together with the public keycertificate of A. Since Ra and Rb have each 64 bits, and the Xcoordinate and the Y coordinate of Av each have 160 bits, a digitalsignature for a total of 448 bits is generated.

[0741] When using the public key certificate, the user verifies thedigital signature of the public key certificate by using the public keyof the public key certificate issuing authority (CA) owned by the user.After succeeding in authenticating the digital signature, the userextracts the public key from the public key certificate and utilizes it.Accordingly, it is necessary that all the users of the public keycertificate possess the common public key of the public key certificateissuing authority (CA). The verification method of the digital signaturehas been discussed with reference to FIG. 13, and details thereof arethus omitted.

[0742] Upon receiving the public key certificate of A, Ra, Rb, Av, andthe digital-signature A. Sig, B determines whether Rb sent from Acoincides with Rb generated by B. After determination, if two Rbcoincide with each other, B verifies the digital signature of the publickey certificate of A by using the public key of the certificateauthority, and extracts the public key of A. Then, B verifies thedigital signature A. Sig by using the extracted public key of A. Aftersucceeding in the verification of the digital signature, B determinesthat A is authenticated.

[0743] Then, B generates a random number Bk, which is smaller than thecharacteristic p. Then, the point Bv is calculated by multiplying thebase point G by Bk (Bv=Bk×G), and the digital signature B. Sig for Rb,Ra, and Bv (X coordinate and Y coordinate) is generated. B sends thedigital signature B. Sig to A together with the public key certificateof B.

[0744] Upon receiving Rb, Ra, Bv, and the digital signature B. Sig, Adetermines whether Ra sent from B coincides with Ra generated by A.After determination, if two Ra coincide with each other, A verifies thedigital signature of the public key certificate of B by using the publickey of the certificate authority, and extracts the public key of B.Then, A verifies the digital signature B. Sig by using the extractedpublic key of B. After succeeding in the verification of the digitalsignature, A determines that B is authenticated.

[0745] If the authentication of both A and B has succeeded, B calculatesBk×Av (since Av is the point on the elliptic curve, the scalar productcalculation on the point on the elliptic curve is required, though Bk isa random number), and A calculates Ak×Bv. Then, the lower 64 bits of theX coordinate of these points are used as the session key, which is usedfor the subsequent communication (when a 64-bit common key is used forthe common key cryptosystem). The session key may be generated by the Ycoordinate, and the lower 64 bits do not have to be used for the sessionkey. In the private communication after mutual authentication, thetransmitting data is not only encrypted, but also may be provided with adigital signature.

[0746] If the illegalities or the inconsistencies are found during theverification of the digital signature or the received data, it isdetermined that the mutual authentication has failed, and the process isterminated.

[0747] In the mutual authentication processing, the transmitting data isencrypted by using the generated session key, and mutual datacommunication is then performed.

[0748] Referring back to FIG. 49, a description of the flow iscontinued. After the above-described mutual authentication and keysharing processing has succeeded in steps S453 and S463, the devicedetermines in step S464 whether the device authentication unit to becommunicated is not revoked, by referring to the CRL_DEV: the revocationlist (Revocation List (Certificate)) stored in the device key area (seeFIG. 18) of the device memory, in which the public key certificateidentifiers (ex. serial number: SN) of the revoked devices and therevoked units (a ticket user, such as a reader/writer or a PC as thedevice access unit, or ticket issuing means) are registered. If thedevice authentication unit is revoked, the partition creation processingcannot be permitted, and thus, the process is terminated as an error.

[0749] If the device authentication unit is not revoked, in step S465,the session key Kses generated in the mutual authentication and keysharing processing, the ID name (DN: Distinguished Name), the serialnumber, and the category in the public key certificate of the entity tobe communicated (a reader/writer or a PC forming the deviceauthentication unit as a device access unit) are stored in theauthentication table in such a manner that they are related to eachother by using the device manager code (DMC) as a key.

[0750] Meanwhile, in step S454, the device authentication unitdetermines whether the device is not revoked by referring to CRL_DEV:the revocation list (Revocation List (Certificate)) in which the publickey certificate identifiers (ex. serial number: SN) of the revokeddevices and the revoked units (a ticket user, such as a reader/writer ora PC as the device access unit, or ticket issuing means) are registered.The device authentication unit is able to obtain the revocation list(CRL_DEV) from the registration authority (RA(PAR)). If the device isrevoked, the partition creation processing cannot be permitted, and theprocess is terminated as an error.

[0751] If the device is not revoked, in step S455, the session key Ksesgenerated in the mutual authentication and key sharing processing, theID name (DN: Distinguished Name), the serial number, and the category inthe public key certificate of the entity to be communicated (device) arestored in the authentication table in such a manner that they arerelated to each other by using the device manager code (DMC) as a key.

[0752]FIG. 51 illustrates an example of the authentication table createdin the device. FIG. 52 illustrates an example of the authenticationtable created in the reader/writer (may be a PC) as the device accessunit, which serves as the authentication unit.

[0753]FIG. 51 illustrates an example of the authentication table createdin the device when the device authentication and the authentication ofpartitions 1 and 2 as the partition authentication, which is describedbelow, are finished. As the group, the device manager code (DMC) isrecorded for the device authentication, and the partition manager code(PMC) is recorded for the partition authentication. Data of each groupis stored according to the executed authentication type. When the publickey authentication type is employed, as discussed above, the session keyKses generated in the mutual authentication and key sharing processing,the ID name (DN: Distinguished Name), the serial number, and thecategory in the public key certificate of the entity to be communicated(reader/writer as the device access unit) are stored in theauthentication table in such a manner that they are related to eachother by using the device manager code (DMC) as a key. When the commonkey authentication type is employed, the session key Kses and theidentifier (ID RW) of the entity to be communicated (reader/writer asthe device access unit) are stored.

[0754] The authentication table is discarded when the session iscleared. The device is able to check the authentication status of thedevice and that of each partition by referring to the table information,and is able to check the session key to be used.

[0755]FIG. 52 illustrates the authentication table in the reader/writeras the device access unit. FIG. 52 also illustrates the authenticationtable when the device authentication and the authentication ofpartitions 1 and 2 as the partition authentication are finished. Thebasic configuration of this authentication table is similar to that ofthe device. As the group, the device manager code (DMC) is recorded forthe device authentication, and the partition manager code (PMC) isrecorded for the partition authentication. Data of each group is storedaccording to the executed authentication type. When the public keyauthentication type is employed, as discussed above, the session keyKses, the ID name (DN: Distinguished Name), the serial number, and thecategory in the public key certificate of the entity to be communicated(device) are stored in the table. When the common key authenticationtype is employed, the session key Kses and the identifier (ID RW) of theentity to be communicated (device) are stored. The authentication tableof the reader/writer is also discarded when the session is cleared. Thereader/writer as the device access unit is also able to determine theauthentication status of the device and that of each partition byreferring to the information of the authentication table, and is able tocheck the session key to be used.

[0756] Referring back to FIG. 49, a description of the deviceauthentication processing is continued. If it is determined in step S451that the device authentication type is not a public key type, the deviceauthentication unit outputs a common-key device authentication commandto the device in step S456. Upon receiving the command (S466), thedevice checks whether the two-way individual key authentication masterkey (MKauth_DEV) used for the common key authentication is stored byreferring to the common-key device key definition block (see FIG. 16) ofthe device memory (S467). If the two-way individual key authenticationmaster key (MKauth_DEV) is not stored, the common-key mutualauthentication cannot be executed, and the process is terminated as anerror.

[0757] If it is determined that the two-way individual keyauthentication master key (MKauth_DEV) is stored, the mutualauthentication using the master key and key sharing processing isexecuted in steps S457 and S468.

[0758] The mutual authentication and key sharing processing according tothe common key using the master key is described below with reference toFIG. 53. In FIG. 53, A and B indicate entities that execute the commonkey authentication by using the master key. A possesses the identifierof A IDa, the two-way individual key authentication common key Ka, andthe two-way individual key authentication master key MKb, and Bpossesses the identifier IDb of B, the two-way individual keyauthentication common key Kb, and the two-way individual keyauthentication master key MKa. In the example shown in FIG. 53, the DESalgorithm (ex. DES or triple DES) is used as the common keycryptosystem. However, another type of common key cryptosystem similarto DES may be used.

[0759] First, B generates a 64-bit random number Rb, and sends Rb andIDb, which is the ID of B, to A. Upon receiving Rb and IDb, A generatesa new 64-bit random number Ra, and obtains the two-way individual keyauthentication common key Kb by DES-encrypting IDb with the two-wayindividual key authentication master key MKb. A then encrypts data inthe CBC mode of DES by using the keys Ka and Kb in the order of Ra, Rb,IDa, and IDb, and returns the encrypted data to B together with theidentifier IDa of A.

[0760] Upon receiving the data, B obtains the two-way individual keyauthentication common key Ka by DES-encrypting IDa with the two-wayindividual key authentication master key MKa. B also decrypts thereceived data with the keys Ka and kb. B then verifies whether Rb andIDb among the decrypted Ra, Rb, IDa, and IDb coincide with those sentfrom B. If the verification has succeeded, B determines that A isauthenticated.

[0761] Then, B generates a 64-bit random number Kses used as the sessionkey, encrypts the data in the CBC mode of DES by using the keys Kb andKa in the order of Rb, Ra, IDb, IDa, and Kses, and returns the data toA.

[0762] Upon receiving the data, A decrypts the received data with thekeys Ka and Kb, and verifies whether the decrypted Ra, Rb, IDa, and TDbcoincide with those sent from A. If the verification has succeeded, Adetermines that B is authenticated. After authenticating A and B eachother, the session key Kses is used as the common key for performingprivate communication after authentication.

[0763] If the illegalities or the inconsistencies are found during theverification of the received data, it is determined that the mutualauthentication has failed, and the process is terminated.

[0764]FIG. 54 illustrates the data flow in the common key authenticationusing the master key in correspondence with the storage data of thesystem of the present invention. As shown in FIG. 54, the reader/writer(R/W) as the device access unit generates a 64-bit random number Rb, andsends Rb and IDrw, which is the ID of the reader/writer, to the device.Upon receiving Rb and IDrw, the device generates a new 64-bit randomnumber Ra, and obtains the two-way individual key authentication commonkey Kauth_DEV_A by DES-encrypting IDrw with the two-way individual keyauthentication master key MKauth_DEV_A. The device then encrypts thedata, for example, in the DES-CBC mode as the encryption algorithm, byusing the keys Kauth_DEV_A and Kauth_DEV_B in the order of Ra, Rb, andIDrw, and returns the encrypted data to the reader/writer (R/W) as thedevice access unit together with the identifier IDm of the device.

[0765] Upon receiving the encrypted data and the identifier IDm, thereader/writer (R/W) obtains the two-way individual key authenticationcommon key Kauth_DEV_B by DES-encrypting IDm with the two-way individualkey authentication master key MKauth_DEV_B. The reader/writer thendecrypts the received data with the keys Kauth_DEV_A and Kauth_DEV_B,and verifies whether the decrypted Rb and IDrw coincide with those sentfrom the reader/writer (R/W) as the device access unit. After theverification has succeeded, the reader/writer (R/W) determines that thedevice is authenticated.

[0766] Subsequently, the reader/writer (R/W) generates a 64-bit randomnumber Kses used as the session key, encrypts the data, for example, inthe triple DES mode as the DES algorithm, by using the two-wayindividual key authentication common keys Kauth_DEV_A and Kauth_DEV_B inthe order of Rb, Ra, and Kses, and returns the encrypted data to thedevice.

[0767] Upon receiving the data, the device decrypts the received datawith the two-way individual key authentication common keys Kauth_DEV_Aand Kauth_DEV_B. The device verifies whether the decrypted Ra, Rb, andIDrw coincide with those sent from the device. After the verificationhas succeeded, the device determines that the reader/writer (R/W) isauthenticated, and the session key Kses is used as the common key forthe private communication after authentication.

[0768] Concerning IDm, which is the unique value of the device, thevalues of the storage data in the device manager management area can beused for IDm, as previously discussed by using the device memory formatof FIG. 6.

[0769] As discussed above, according to the mutual authentication andkey sharing processing by employing the common key type using the masterkey, two keys, such as the individual key of one of the two entities tobe communicated, and the individual key of the other entity, which isgenerated by the processing based on the master key of the other entity,are set as the common key, and mutual authentication is performedaccording to the common key type by using the two keys. It is thuspossible to implement a more secure authentication system and methodthan a known common key authentication system, which is configured suchthat a common key is prestored in a device or an access unit.

[0770] Referring back to FIG. 49, a description of the flow iscontinued. If the above-described mutual authentication and key sharingprocessing have succeeded in steps S457 and S468, the device verifies instep S469 whether the entity to be communicated, i.e., the deviceauthentication unit, is not revoked by referring to IRL_DEV: therevocation list (Revocation List (ID)), stored in the device key area(see FIG. 18) of the device memory, in which the identifiers (IDs) ofthe revoked devices and the revoked units (a ticket user, such as areader/writer or a PC as the device access unit, or ticket issuingmeans) are registered. If the device authentication unit is revoked, thepartition creation processing cannot be permitted, and the process isterminated as an error.

[0771] If the device authentication unit is not revoked, the devicestores the session key Kses created in the mutual authentication and keysharing processing, in step S470, the ID information (IDrw) of theentity to be communicated (a reader/writer or a PC forming the deviceauthentication unit as the device access unit) in the authenticationtable (see FIG. 51) in such a manner that they are related to each otherby using the device manager code (DMC) as a key.

[0772] Meanwhile, in step S458, the device authentication unit alsoverifies whether the device is not revoked by referring to IRL_DEV: therevocation list (Revocation List (ID)) in which the identifiers (IDs) ofthe revoked devices and the revoked units (a ticket user, such as areader/writer or a PC as the device access unit, or ticket issuingmeans) are registered. The device authentication unit is able to obtainthe revocation list (IRL_DEV) from the registration authority (RA(PAR)).If the device is revoked, the partition creation processing cannot bepermitted, and the process is terminated as an error.

[0773] If the device is not revoked, in step S459, the deviceauthentication unit stores the session key Kses created in the mutualauthentication and key sharing processing and the ID information (IDm)of the entity to be communicated (device) in the authentication table(see FIG. 52) in such a manner that they are related to each other byusing the device manager code (DMC) as a key.

[0774] The above-described processing is the device authenticationprocessing between the device and the reader/writer as the device accessunit managed by the partition manager.

[0775] The partition authentication processing executed in step S435 orS442 of FIG. 48 is described below with reference to FIGS. 55 and 56. Aspreviously discussed, for performing the partition setting registrationor deletion processing using the partition registration ticket, eitherthe device authentication or the partition authentication or bothauthentications are required according to the type of processing. Suchsetting is indicated in the partition registration ticket (PRT). If thepartition registration ticket (PRT) indicates that the partitionauthentication is to be performed, the partition authentication isexecuted.

[0776] The individual steps of the processing flows of FIGS. 55 and 56are discussed below. In FIG. 55, the processing of the partitionauthentication unit of the partition manager is shown at the left side,and the processing of the device (see FIG. 5) is shown at the rightside. The partition authentication unit of the partition manager is aunit that can read and write data from and into the device (ex. areader/writer or a PC as the device access unit), and has theconfiguration of a reader/writer, such as that shown in FIG. 10, whichserves as the device access unit.

[0777] In step S471, the partition authentication unit outputs apartition-A presence check command for identifying the presence ofpartition A, which is to be authenticated, to the device. Upon receivingthe command (S481), the device checks for the presence of the partitionA in the device memory (S482). In this case, as the partition identifierA, for example, the partition manager code (PMC) is used, and the deviceis able to check for the presence of the partition based on the PMCstored in the partition definition block (PDB). When determining thepresence or the absence of the partition, the check result is sent tothe partition authentication unit.

[0778] Upon receiving the check result (S472), the partitionauthentication unit determines the check result (S473). If the resultindicates that the partition is not present, the authentication cannotbe performed, and thus, the process is terminated as an error. If thecheck result indicates that the partition is present, in step S474, thepartition authentication unit determines based on the partitionregistration ticket (PRT) whether the public key cryptosystem using apublic key is to be employed for the partition authenticationprocessing. As in the above-described device authentication, either thepublic key system or the common key system is used for the partitionauthentication, and the execution type is specified in the ticket.

[0779] If the common key system is specified, steps S475 through S478and steps S484 through S488 of FIG. 55 are not executed, and the processproceeds to step S491. If the public key system is specified, in stepS475, the partition authentication unit sends a public-key partition-Aauthentication start command to the device. Upon receiving the command(S484), the device refers to the public-key partition key definitionblock (see FIG. 21) of the device memory, and determines whether thepartition-A public key certificate (CERT PAR) is stored (S485). If thepartition-A public key certificate (CERT PAR) is not stored, thepublic-key mutual authentication cannot be performed, and the process isterminated as an error.

[0780] If it is determined that the partition-A public key certificate(CERT PAR) is stored, in steps S476 and S486, the mutual authenticationand key sharing processing is performed by using the public keycertificate issued by the partition-manager certificate authority(CA(PAR)).

[0781] The public-key mutual authentication and key sharing processingis similar to the sequence shown in FIG. 50 discussed in the deviceauthentication processing, and an explanation thereof is thus omitted.However, the pubic key certificate used in the partition authenticationis a public key certificate issued by the partition-manager certificateauthority (CA(PAR)), and the signature of this public key certificate isverified by the public key (PUB CA(PAR)) of the partition-managercertificate authority (CA(PAR)). The public key (PUB CA(PAR)) is storedin the partition key area (see FIG. 23). In the mutual authenticationprocessing, the data to be sent is encrypted by using the generatedsession key, and the data communication is then performed.

[0782] If the mutual authentication and key processing according to thesequence shown in FIG. 50 has succeeded in steps S476 and S486, thedevice verifies in step S487 whether the entity to be communicated,i.e., the partition authentication unit, is not revoked by referring toCRL_PAR: the revocation list (Revocation List (Certificate)), which isstored in the partition key area (see FIG. 23) of the device memory, inwhich the public key certificate identifiers (ex. serial number: SN) ofthe revoked devices and the revoked units (a ticket user, such as areader/writer or a PC, as the device access unit, or ticket issuingmeans) are registered. If the partition authentication unit is revoked,the partition creation processing or deletion processing cannot bepermitted, and the process is terminated as an error.

[0783] If the partition authentication unit is not revoked, in stepS488, the session key Kses generated in the mutual authentication andkey sharing processing, and the ID name (DN: Distinguished Name), theserial number, and the category in the public key certificate of theentity to be communicated (a reader/writer or a PC forming the partitionauthentication unit, which serves as the device access unit) are storedin the authentication table in such a manner that they are related toeach other by using the partition manager code (PMC) as a key.

[0784] Meanwhile, in step S477, the partition authentication unit alsodetermines whether the device is not revoked by referring to CRL_PAR:the revocation list (Revocation List (Certificate)) in which the publickey certificate identifiers (ex. serial number: SN) of the revokeddevices and the revoked units (a ticket user, such as a reader/writer ora PC as the device access unit, or ticket issuing means) are registered.The device authentication unit is able to obtain the revocation list(CRL_PAR) from the registration authority (RA(PAR)). If the device isrevoked, the partition creating processing or deletion processing cannotbe permitted, and the process is terminated as an error.

[0785] If the device is not revoked, in step S478, the session key Ksesgenerated in the mutual authentication and key sharing processing, andthe ID name (DN: Distinguished Name), the serial number, and thecategory in the public key certificate of the entity to be communicated(device) are stored in the authentication table in such as manner thatthey are related to each other by using the partition manager code (PMC)as a key. As a result, for example, the authentication table shown inFIG. 51 is created in the device, and the authentication table shown inFIG. 52 is created in the reader/writer (may be a PC) as the deviceaccess unit, which serves as the partition authentication unit. FIGS. 51and 52 illustrate examples of the authentication tables created in thedevice and the reader/writer as the device access unit, respectively,when the device authentication and the authentication of partitions 1and 2 are finished.

[0786] In the partition authentication, the partition manager code (PMC)is recorded, and data is stored according to the executed authenticationtype. For the public key authentication type, as discussed above, thesession key Kses, and the ID name (DN: Distinguished Name), the serialnumber, and the category in the public key certificate of the entity tobe communicated are stored in the table. For the common keyauthentication, as discussed above, the session key Kses and theidentifier of the entity to be communicated are stored. Theauthentication table is discarded when the session is cleared. Thedevice and the reader/writer as the device access unit are able to checkthe authentication status of the device and that of each partition byreferring to the table information so that they can check the sessionkey to be used.

[0787] A description of the partition authentication processing iscontinued by using the flows of FIGS. 55 and 56. If it is determined instep S474 that the public key system is not used as the partitionauthentication type, the partition authentication unit outputs acommon-key partition-A authentication command to the device in stepS491. Upon receiving the command (S501), the device verifies whether thetwo-way individual key authentication master key (MKauth_PAR_A) used forthe common key authentication is stored by referring to the common-keypartition key definition block (see FIG. 22) of the device memory(S502). If the two-way individual key authentication master key(MKauth_PAR_A) is not stored, the common-key mutual authenticationcannot be executed, and the process is terminated as an error.

[0788] If it is determined that the two-way individual keyauthentication master key (MKauth_PAR_A) is stored, in steps S492 andS503, the mutual authentication and key sharing processing using themaster key is performed. The mutual authentication and key sharingprocessing according to the common key type is similar to the sequencedescribed in the foregoing device authentication with reference to FIGS.53 and 54, and an explanation thereof is thus omitted. However, the keysused for the partition authentication are defined in the partition keydefinition block (see FIG. 22), and they are the two-way individual keyauthentication common key (Kauth_PAR_B) and the two-way individual keyauthentication master key (MKauth_PAR_A) stored in the partition keyarea (see FIG. 23).

[0789] If the common-key mutual authentication and key sharingprocessing has succeeded in steps S492 and S503, the device verifies instep S504 whether the entity to be communicated, i.e., the partitionauthentication unit, is not revoked by referring to IRL_PAR: therevocation list (Revocation List (ID)), which is stored in the partitionkey area (see FIG. 23) of the device memory, in which the identifiers(IDs) of the revoked devices and the revoked units (a ticket user, suchas a reader/writer or a PC, as the device access unit, or the ticketissuing means) are registered. If the partition authentication unit isrevoked, the partition creating processing or deletion processing cannotbe permitted, and the process is terminated as an error.

[0790] If the partition authentication unit is not revoked, in stepS505, the session key Kses created in the mutual authentication and keysharing processing, and the ID information (IDrw) of the entity to becommunicated (a reader/writer or a PC forming the device authenticationunit, which serves as the device access unit) are stored in theauthentication table (see FIG. 51) in such a manner that they arerelated to each other by using the partition manager code (PMC) as akey.

[0791] Meanwhile, in step S493, the partition authentication unit alsodetermines whether the device is not revoked by referring to IRL_PAR:the revocation list (Revocation List (ID)) in which the identifiers(IDs) of the revoked devices and the revoked units (a ticket user, suchas a reader/writer or a PC, which serves as the device access unit, orthe ticket issuing means) are registered. The partition authenticationunit is able to obtain the revocation list (IRL_PAR) from theregistration authority (RA(PAR)). If the device is revoked, thepartition creation processing or deletion processing cannot bepermitted, and the process is terminated as an error.

[0792] If the device is not revoked, in step S494, the session key Ksescreated in the mutual authentication and key sharing processing, and theID information (IDm) of the entity to be communicated (device) arestored in the authentication table (see FIG. 52) in such a manner thatthey are related to each other by using the partition manager code (PMC)as a key.

[0793] The foregoing processing is the partition authenticationprocessing executed between the device and the reader/writer as thedevice access unit managed by the partition manager. According to thisauthentication processing, the authentication has conducted between thedevice or the partition and the reader/writer as the device access unit,and the sharing of the session key is achieved, thereby making ispossible to perform encrypted data communication by using the sessionkey.

[0794] The above-described device authentication processing andpartition authentication processing can also be performed as requiredwhen conducting a device access using a different ticket, such as thefile registration ticket (FRT), the service permission ticket (SPT), orthe data update ticket (DUT). This is discussed below while describingthe processings performed using such tickets.

[0795] (Integrity Checking of Ticket and User)

[0796] In the flow of the partition creation/deletion processing shownin FIG. 47, details of the integrity checking of the ticket and the userby the device in step S413 are discussed below with reference to theflows of FIGS. 57 and 58.

[0797] The subsequent integrity checking of the ticket and the user canalso be performed for device access processing using a different ticket,such as the file registration ticket (FRT), the service permissionticket (SPT), or the data update ticket (DUT), as required. Thus, theflows shown in FIGS. 57 and 58 are formed as the common processing flowsfor the tickets.

[0798] The integrity checking of the ticket and the user is theprocessing executed by the device (see FIG. 5) based on the ticketreceived from a ticket user (ex. a reader/writer or a PC as the deviceaccess unit) that is communicating with the device. After verifying theintegrity of the ticket and the user, which is the ticket user (areader/writer or a PC as the device access unit) in the integritychecking processing of the ticket and the user, the device permits theprocessing within the restriction indicated in the ticket.

[0799] Details of the integrity checking processing of the ticket andthe user are described below with reference to the flows of FIGS. 57 and58. Upon receiving a ticket from the ticket user (ex. a reader/writer ora PC as the device access unit), in step S511 of FIG. 57, the devicechecks the ticket type and determines whether the ticket is a partitionregistration ticket (PRT). The ticket type is recorded in each ticket(see FIGS. 26, 27, 28, 31, and 32).

[0800] If the ticket type is the partition registration ticket (PRT),the steps S512 through S514 are executed, and if the ticket type is notthe partition registration ticket (PRT), the process proceeds to stepS515.

[0801] If the ticket type is the partition registration ticket (PRT), itis determined in step S512 whether the setting of the integrity checktype (public key system (Public)/common key system (Common)) indicatedin the ticket is the public key system (Public).

[0802] If the integrity check type is the public key system (Public),the process proceeds to step 513 in which the various processings areperformed. The processing executed in step S513 is started by verifyingthe public key certificate (CERT) of the ticket issuer using the publickey PUB CA(DEV) of the device-manager certificate authority (CA(DEV)).

[0803] As discussed above, when sending the ticket issued by thepartition registration ticket (PRT) issuing means (PRT Issuer) to theticket user, the public key certificate (CERT_PRTI) of the partitionregistration ticket (PRT) issuing means (PRT Issuer) is also senttogether to the device if the public key system is employed. Theattribute of the public key certificate (CERT_PRTI) of the PRT issuingmeans coincides with the identifier (PRTIC) of the partitionregistration ticket (PRT) issuing means (PRT User).

[0804] The signature implemented by the private key of thedevice-manager certificate authority (CA(DEV)) is added to the publickey certificate (see FIG. 11), and this signature is verified by usingthe public key PUB CA(DEV) of the device-manager certificate authority(CA(DEV)). The signature creation and verification is executed accordingto the flows shown in FIGS. 12 and 13. By this signature verification,it can be determined whether the public key certificate (CERT) of theticket issuer is an authorized public key certificate (CERT) withoutbeing tampered with.

[0805] In step S513, it is also determined whether the code as the usercategory recorded in the option area of the public key certificate(CERT), which is verified by the signature verification of the ticketissuing means, of the ticket issuing means coincides with the ticketissuing means code (PRTIC: PRT Issuer Code) recorded in DKDB (Device KeyDefinition Block)(PUB) in the device.

[0806] As discussed in the section of the public key certificate shownin FIG. 11, in the public key certificate, the code of the ticketissuing means (Ticket Issuer), which is the ticket (PRT, FRT, or SPT)issuing means, is recorded, and in this case, the PRTIC (PRT IssuerCode) is recorded. By checking the consistency between the code in thisoption area and the ticket issuing means code (PRTIC: PRT Issuer Code)recorded in the DKDB (Device Key Definition Block)(PUB) in the device,it is determined whether the received ticket (PRT) is a ticket issued bythe authorized ticket issuing means.

[0807] The device also determines whether the ticket issuing means(Ticket Issuer) is not revoked by referring to CRL_DEV: the revocationlist (Revocation List (Certificate)), which is stored in the device keyarea (see FIG. 18) of the device memory, in which the pubic keycertificate identifiers (ex. serial number: SN) of the revoked devicesand revoked units (a ticket user, such as a reader/writer or a PC, asthe device access unit, or ticket issuing means) are registered.

[0808] It is also determined whether the ticket has not been tamperedwith by verifying the signature recorded in the partition registrationticket (PRT) (see FIG. 26), i.e., the integrity check value (public keysystem: signature) of the ticket. The signature integrity is performedin a manner similar to the signature integrity of the public keycertificate, for example, according to the sequence of the flow shown inFIG. 13.

[0809] Accordingly, it has been checked that: (1) the public keycertificate (CERT) of the ticket issuer is an authorized public keycertificate (CERT) without being tampered with; (2) the code recorded inthe option area of the public key certificate (CERT) of the ticketissuer coincides with the ticket issuing means code (PRTIC: PRT IssuerCode) recorded in DKDB (Device Key Definition Block)(PUB) in the device;(3) the ticket issuing means (Ticket Issuer) is not revoked; and (4) theticket has not been tampered with by verifying the signature of thereceived ticket (PRT). Only when all the conditions (1) through (4) aresatisfied, it can be determined that the ticket integrity has beensuccessfully verified. If any of the conditions (1) through (4) is notsatisfied, it is determined that the ticket integrity has not beensuccessfully verified, and the processing using the partitionregistration ticket (PRT) is terminated.

[0810] If it is determined in step S512 that the setting of theintegrity check type (public key system (Public)/common key system(Common) of the ticket is the common key system, the process proceeds tostep S514 in which the MAC (Message Authentication Code) checking isperformed. The device performs the MAC checking processing of the ticketby using the MAC checking key of the partition registration ticket(PRT): Kprt, which is stored in the device key area (see FIG. 18) of thedevice.

[0811]FIG. 59 illustrates an example of a MAC value, which is created byusing a DES encryption configuration. In the configuration shown in FIG.59, a target message is divided into 8-byte units (hereinafter thedivided messages are indicated by M1, M2, . . . , MN), and the exclusiveOR is performed on the initial value (hereinafter referred to as “IV”)and M1 (the resulting value is set to I1). Then, I1 is input into a DESencryption unit, and is encrypted by using the MAC checking key: Kprt(the output is set to E1). Subsequently, the exclusive OR is performedon E1 and M2, and the resulting output I2 is input into a DES encryptionunit and is encrypted by using the key Kprt (output E2). Subsequently,the above-described process is repeated to encrypt all the messages. Thefinal output EN is set to the message authentication code (MAC). As themessage, part of the data to be checked can be used.

[0812] The integrity-guaranteed ICV (Integrity Check Value) generatedby, for example, a data sender in the data sender, is compared with theICV generated based on the received data by a data receiver. If the twoICVs coincide with each other, it can be guaranteed that the data hasnot been tampered with. If the two ICVs are different, it is determinedthat the data has been tampered with. The integrity-guaranteed ICVgenerated in the data creation by the data sender is stored in the ICV(Integrity Check Value) field in the PRT, as has been discussed in thedescription of the partition registration ticket (PRT) format shown inFIG. 26. If the ICV generated by the device coincides with the ICVstored in the received ticket (PRT) after comparison, it is determinedthat the integrity of the ticket has been verified. If the two ICVs aredifferent, it is determined that the ticket has been tampered with, andthe processing using the ticket is terminated.

[0813] According to the above-described processing, the ticket checkingprocessing when the integrity check type is the common key system iscompleted.

[0814] Referring back to the flow of FIG. 57, a description of theintegrity checking of the ticket and the user is continued. If it isdetermined in step S511 that the ticket type is not the partitionregistration ticket (PRT), it is determined in step S515 whether theticket type is the file registration ticket (FRT).

[0815] If the ticket type is the file registration ticket (FRT), stepsS516 through S518 are executed, and if the ticket type is not the fileregistration ticket (FRT), the process proceeds to step S519.

[0816] If the ticket type is the file registration ticket (FRT), it isdetermined in step S516 whether the setting of the integrity check type(public key system (Public)/common key system (Common) indicated in theticket is the public key system (Public).

[0817] If the integrity check type is the public key system (Public),the process proceeds to step S517 in which various processings areexecuted. The processing executed in step S517 is started by verifyingthe public key certificate (CERT) of the ticket issuer by using thepublic key PUB CA(PAR) of the partition-manager certificate authority(CA(PAR)).

[0818] When sending the ticket issued by the file registration ticket(FRT) issuing means (FRT Issuer) to the ticket user, the public keycertificate (CERT_FRTI) of the file registration ticket (FRT) issuingmeans (FRT Issuer) is also sent together to the device. The attribute ofthe public key certificate (CERT_FRTI) of the FRT issuing meanscoincides with the identifier (FRTIC) of the file registration ticket(FRT) issuing means (FRT Issuer).

[0819] The signature implemented by the private key of thepartition-manager certificate authority (CA(PAR)) is added to the publickey certificate (see FIG. 11), and this signature is verified by usingthe public key PUB CA(PAR) of the partition-manager certificateauthority (CA(PAR)). The signature creation and verification is executedaccording to the above-described flows of FIGS. 12 and 13. By thissignature verification, it can be determined whether the public keycertificate (CERT) of the ticket issuer is an authorized public keycertificate (CERT) without being tampered with.

[0820] In step S517, it is also determined whether the user categorycode recorded in the option area of the public key certificate (CERT),which has been verified by the signature verification, of the ticketissuing means coincides with the ticket issuing means code (FRTIC: FRTIssuer Code) recorded in PKDB (Partition Key Definition Block)(PUB) inthe device.

[0821] In the public key certificate, the category code of the ticketissuing means (Ticket Issuer), which is the issuing means of each ticket(PRT, FRT, or SPT), in this case, the FRTIC (FRT Issuer Code), isrecorded, as discussed in the description of the public key certificatewith reference to FIG. 11. By checking the consistency between the codein the option area and the ticket issuing means code (FRTIC: FRT IssuerCode) recorded in PKDB (Partition Key Definition Block)(PUB) in thedevice, it can be determined that the received ticket (FRT) is a ticketissued by the authorized ticket issuing means.

[0822] The device also determines whether the ticket issuing means(Ticket Issuer) is not revoked by referring to CRL_PAR: the revocationlist (Revocation List (Certificate)), which is stored in the partitionkey area (see FIG. 23) of the device memory, in which the public keycertificate identifiers (ex. serial number: SN) of the revoked devicesand the revoked units (a ticket user, such as a reader/writer or a PC,as the device access unit, or ticket issuing means) are registered.

[0823] The device also verifies the signature recorded in the fileregistration ticket (FRT) (see FIG. 27), which is the received ticket,i.e., the integrity check value (public key system: signature), anddetermines whether the ticket has not been tampered with. As in theabove-described signature verification of the public key certificate,the signature verification is executed according to the sequence similarto the flow of FIG. 13.

[0824] Thus, it has been checked that: (1) the public key certificate(CERT) of the ticket issuer is an authorized public key certificate(CERT) without being tampered with; (2) the code recorded in the optionarea of the public key certificate (CERT) of the ticket issuer coincideswith the ticket issuing means code (FRTIC: FRT Issuer Code) recorded inPKDB (Partition Key Definition Block)(PUB) in the device; (3) the ticketissuing means (Ticket Issuer) is not revoked; and (4) the ticket has notbeen tampered with by verifying the signature of the received ticket(FRT). Only when all the conditions (1) through (4) are satisfied, itcan be determined that the integrity of the received ticket (FRT) hasbeen successfully verified. If any of the conditions (1) through (4) isnot satisfied, it is determined that the integrity of the fileregistration ticket (FRT) has not been successfully verified, and theprocessing using the file registration ticket (FRT) is terminated.

[0825] If it is determined in step S516 that the setting of theintegrity check type (public key system (Public)/common key system(Common) of the ticket is the common key system (Common), the processproceeds to step S518 in which the MAC (Message Authentication Code)checking is performed. The device performs the MAC checking processingof the ticket by using the MAC checking key of the file registrationticket (FRT): Kfrt, which is stored in the partition key area (see FIG.23) of the device. The MAC checking processing is executed according tothe above-described MAC-value creation processing using the DESencryption configuration shown in FIG. 59.

[0826] The integrity-guaranteed ICV (Integrity Check Value) generatedby, for example, a data sender, during the data creation is comparedwith the ICV generated based on the received data by a data receiver. Ifthe two ICVs coincide with each other, it is verified that the data hasnot been tampered with. If the two ICVs are different, it is determinedthat the data has been tampered with. The integrity guaranteed ICVgenerated by, for example, a data sender, during the data creation isstored in the ICV (Integrity Check Value) field of FRT, as has beendiscussed in the description of the file registration ticket (FRT)format shown in FIG. 27. If the ICV generated by the device coincideswith the ICV stored in the received ticket (FRT) after comparison, it isdetermined that the ticket integrity has been verified. If the ICVs aredifferent, it is determined that the ticket has been tampered with, andthe processing using the ticket is terminated.

[0827] According to the foregoing processing, the file registrationticket (FRT) verification processing when the integrity check type isthe common key system is completed.

[0828] If it is determined it step S515 that the ticket type is not thefile registration ticket (FRT), it is determined in step S519 whetherthe ticket type is the service permission ticket (SPT).

[0829] If the ticket type is the service permission ticket (SPT), stepsS520 through S522 are executed. If the ticket type is not the servicepermission ticket (SPT), the process proceeds to step S523.

[0830] If the ticket type is the service permission ticket (SPT), it isdetermined in step S520 whether the integrity check type (public keysystem (Public)/common key system (Common)) indicated in the ticket isthe public key system.

[0831] If the integrity check type is the public key system, the processproceeds to step S521 in which various processings are performed. Theprocessing to be executed in step S521 is started by verifying thepublic key certificate (CERT) of the ticket issuer by using the publickey PUB CA(PAR) of the partition-manager certificate authority(CA(PAR)).

[0832] When sending the ticket issued by the service permission ticket(SPT) issuing means (SPT Issuer) to the ticket user, the public keycertificate (CERT_SPTI) of the service permission ticket (SPT) issuingmeans (SPT Issuer) is also sent together to the device if the public keysystem is employed. The attribute of the public key certificate(CERT_SPTI) of the SPT issuing means coincides with the identifier(SPTIC) of the service permission ticket (SPT) issuing means (SPTIssuer).

[0833] The signature implemented by the private key of thepartition-manager certificate authority (CA(PAR)) is added to the publickey certificate (see FIG. 11), and this signature is verified by usingthe public key PUB CA(PAR) of the partition-manager certificateauthority (CA(PAR)). The signature creation and verification isperformed according to, for example, the above-described flows shown inFIGS. 12 and 13. By this signature verification, it is determinedwhether the public key certificate (CERT) of the ticket issuer is anauthorized public key certificate (CERT) without being tampered with.

[0834] It is determined in step S521 whether the user category coderecorded in the option area of the public key certificate (CERT), whichhas been verified by the signature verification, of the ticket issuingmeans coincides with the ticket issuing means code (SPTIC: SPT IssuerCode) recorded in the file definition block (FDB) in the device.

[0835] As discussed in the section of the public key certificate in FIG.11, in the public key certificate, the category code of the ticketissuing means (Ticket Issuer), which is the issuing means of the ticket(PRT, FRT, or SPT), in this case, SPTIC (SPT Issuer Code), is recorded.By checking the consistency between the code in the option area and theticket issuing means code (SPTIC: SPT Issuer Code) recorded in FDB (FileDefinition Block) in the device, it is determined whether the receivedticket (SPT) is issued by authorized ticket issuing means.

[0836] The device also determines whether the ticket issuing means(Ticket Issuer) is not revoked by referring to CRL_PAR: the revocationlist (Revocation List (Certificate)), which is stored in the partitionkey area (see FIG. 23) of the device memory, in which the public keycertificate identifiers (ex. serial number: SN) of the revoked devicesand the revoked units (a ticket user, such as a reader/writer or a PC,as the device access unit, or ticket issuing means) are registered.

[0837] The device also verifies the signature recorded in the servicepermission ticket (SPT) (see FIGS. 28 and 31), which is the receivedticket, i.e., the integrity check value of the ticket (public keysystem: signature), and determines whether the ticket has not beentampered with. In the above-described signature verification of thepublic key certificate, the signature verification is performedaccording to, for example, the sequence similar to the flow shown inFIG. 13.

[0838] Thus, it has been checked that: (1) the public key certificate(CERT) of the ticket issuer is an authorized public key certificate(CERT) without being tampered with; (2) the code recorded in the optionarea of the public key certificate (CERT) of the ticket issuer coincideswith the ticket issuing means code (SPTIC: SPT Issuer Code) recorded inFDB (File Definition Block) in the device; (3) the ticket issuing means(Ticket Issuer) is not revoked; and (4) the ticket has not been tamperedwith by verifying the signature of the received ticket (SPT). Only whenall the conditions (1) through (4) are satisfied, it can be determinedthat the integrity of the service permission ticket (SPT) has beensuccessfully verified. If any of the conditions (1) through (4) is notsatisfied, it is determined that the integrity of the service permissionticket (SPT) has not been successfully verified, and the processingusing the service permission ticket (SPT) is terminated.

[0839] If it is determined in step S520 that the setting of theintegrity check type (public key system (Public)/common key system(Common) of the ticket is the common key system (Common), the processproceeds to step S522 in which the MAC (Message Authentication Code)checking is performed. The device performs the MAC checking processingof the ticket by using the MAC checking key of the service permissionticket (SPT): Kspt, which is stored in the file definition block (seeFIG. 24) of the device. The MAC checking processing is executedaccording to the above-described MAC-value creation processing using theDES encryption configuration shown in FIG. 59.

[0840] The integrity-guaranteed ICV (Integrity Check Value) generatedby, for example, a data sender, during the data creation is comparedwith the ICV generated based on the received data by a data receiver. Ifthe two ICVs coincide with each other, it is verified that the data hasnot been tampered with. If the two ICVs are different, it is determinedthat the data has been tampered with. The integrity-guaranteed ICVgenerated by, for example, a data sender, during the data creation isstored in the ICV (Integrity Check Value) field of SPT, as has beendiscussed in the description of the service permission ticket (SPT)format in FIGS. 28 and 31. If the ICV generated by the device coincideswith the ICV stored in the received ticket (SPT) after comparison, it isdetermined that the ticket integrity has been verified. If the ICVs aredifferent, it is determined that the ticket has been tampered with, andthe processing using the service permission ticket (SPT) is terminated.

[0841] According to the foregoing processing, the service permissionticket (SPT) verification processing when the integrity check type isthe common key system is completed.

[0842] If it is determined in step S519 that the ticket type is not theservice permission ticket (SPT), it is determined in step S523 whetherthe ticket type is the data update ticket-DEV (DUT(DEV)) (see FIG. 32).The data update ticket (DUT) is the access permission ticket, which isstored in the device memory, used for updating various data, asdescribed above. The data update ticket (DUT) includes the data updateticket-DEV (DUT(DEV)) used for updating the management data of thedevice manager and the data update ticket-PAR (DUT(PAR)) used forupdating the management data of the partition manager.

[0843] If the ticket type is the data update ticket-DEV (DUT(DEV)),steps S524 through S528 are executed. If the ticket type is not the dataupdate ticket (DEV) (DUT(DEV)), the process proceeds to step S529.

[0844] If the ticket type is the data update ticket-DEV (DUT(DEV)), itis determined in step S524 whether the integrity check type (public keysystem (Public)/common key system (Common)) indicated in the ticket isthe public key system.

[0845] If the integrity check type is the public key system, the processproceeds to step S525 in which various processings are performed. Theprocessing to be executed in step S525 is started by verifying thepublic key certificate (CERT) of the ticket issuer by using the publickey PUB CA(DEV) of the device-manager certificate authority (CA(DEV)).

[0846] When sending the ticket issued by the data update ticket-DEV(DUT(DEV)) issuing means (DUT Issuer) to the ticket user, the public keycertificate (CERT_DUTI) of the data update ticket (DUT) issuing means(DUT Issuer) is also sent together to the device if the public keysystem is employed. The attribute of the public key certificate(CERT_DUTI) of the DUT issuing means coincides with the identifier(DUTIC) of the ticket issuing means code (DUTIC_DEV) recorded inDKDB(PUB) (Device Key Definition Block)(PUB) in the device.

[0847] The signature implemented by the private key of thedevice-manager certificate authority (CA(DEV)) is added to the publickey certificate (see FIG. 11), and this signature is verified by usingthe public key PUB CA(DEV) of the device-manager certificate authority(CA(DEV)). The signature creation and verification is performedaccording to, for example, the above-described flows shown in FIGS. 12and 13. By this signature verification, it is determined whether thepublic key certificate (CERT) of the ticket issuer is an authorizedpublic key certificate (CERT) without being tampered with.

[0848] It is determined in step S525 whether the user category coderecorded in the option area of the public key certificate (CERT), whichhas been verified by the signature verification, of the ticket issuingmeans coincides with the ticket issuing means code (DUTIC_DEV: DUTIssuer Category for Device) recorded in DKDB(PUB) (Device Key DefinitionBlock)(PUB) in the device.

[0849] As discussed in the section of the public key certificate in FIG.11, in the public key certificate, the category code of the ticketissuing means (Ticket Issuer), which is the issuing means of the ticket(PRT, FRT, SPT, or DUT), in this case, DUTIC (DUT Issuer Code), isrecorded. By checking the consistency between the code in the optionarea and the ticket issuing means code (DUTIC_DEV: DUT Issuer Categoryfor Device) (see FIG. 16) recorded in DKDB(PUB) (Device Key DefinitionBlock)(PUB) in the device, it is determined whether the received ticket(DUT) is issued by authorized ticket issuing means.

[0850] The device also determines whether the ticket issuing means(Ticket Issuer) is not revoked by referring to CRL_DEV, the revocationlist (Revocation List (Certificate)), which is stored in the device keyarea (see FIG. 18) of the device memory, in which the public keycertificate identifiers (ex. serial number: SN) of the revoked devicesand the revoked units (a ticket user, such as a reader/writer or a PC,as the device access unit, or ticket issuing means) are registered.

[0851] The device also verifies the signature recorded in the dataupdate ticket-DEV (DUT(DEV)) (see FIG. 32), which is the receivedticket, i.e., the integrity check value of the ticket (public keysystem: signature), and determines whether the ticket has not beentampered with. As in the above-described signature verification of thepublic key certificate, the signature verification is performedaccording to, for example, the sequence similar to the flow of FIG. 13.

[0852] Thus, it has been checked that: (1) the public key certificate(CERT) of the ticket issuer is an authorized public key certificate(CERT) without being tampered with; (2) the code recorded in the optionarea of the public key certificate (CERT) of the ticket issuer coincideswith the ticket issuing means code (DUTIC_DEV: DUT Issuer Category forDevice) recorded in DKDB(PUB) (Device Key Definition Block)(PUB) in thedevice; (3) the ticket issuing means (Ticket Issuer) is not revoked; and(4) the ticket has not been tampered with by verifying the signature ofthe received ticket (DUT). Only when all the conditions (1) through (4)are satisfied, it can be determined that the integrity of the dataupdate ticket-DEV (DUT(DEV)) has been successfully verified. If any ofthe conditions (1) through (4) is not satisfied, it is determined thatthe integrity of the data update ticket (DUT(DEV)) has not beensuccessfully verified, and the processing using the data updateticket-DEV (DUT(DEV)) is terminated.

[0853] If it is determined in step S524 that the integrity check type(public key system (Public)/common key system (Common)) indicated in theticket is the common key system, it is determined in step S526 whetherthe data indicated by the old data code recorded in the data updateticket-DEV (DUT(DEV)) is Kdut_DEV1 (MAC checking key of the data updateticket (DUT)) or Kdut_DEV2 (data updating encryption key) stored in thedevice key area (see FIG. 18).

[0854] If the data indicated by the old data code (the code of the olddata to be updated) recorded in the data update ticket-DEV (DUT(DEV)) isKdut_DEV1 (MAC checking key of the data update ticket (DUT)) orKdut_DEV2 (data updating encryption key) stored in the device key area(see FIG. 18), the MAC checking processing is performed in step S528 byusing Kdut_DEV3 (MAC checking key of the data update ticket (DUT))stored in the device key area (see FIG. 18). If the data indicated bythe old data code (the code of the old data to be updated) recorded inthe data update ticket-DEV (DUT(DEV)) is not Kdut_DEV1 (MAC checking keyof the data update ticket (DUT)) or Kdut_DEV2 (data updating encryptionkey) stored in the device key area (see FIG. 18), the MAC checkingprocessing is performed in step S527 by using Kdut_DEV1 (MAC checkingkey of the data update ticket (DUT)) stored in the device key area (seeFIG. 18).

[0855] The reason for using the different MAC checking keys, asdescribed above, is as follows. If the data to be updated is Kdut_DEV1(MAC checking key of the data update ticket (DUT)) or Kdut_DEV2 (dataupdating encryption key), the use of such data is to be prohibited forsome reason, for example, due to a leakage of key information.Accordingly, the MAC checking using such data must be avoided. The MACchecking processing is executed according to the above-describedMAC-value creation processing using the DES encryption configurationshown in FIG. 59.

[0856] If Kdut_DEV1 (MAC checking key of the data update ticket (DUT))is newly stored in the device key area (see FIG. 18) of the device, thedevice swaps Kdut_DEV1 and previously stored Kdut_DEV3 (MAC checking keyof the data update ticket (DUT). If Kdut_DEV2 (data updating encryptionkey) is newly stored, the device swaps Kdut_DEV2 and previously storedKdut_DEV4 (data updating encryption key).

[0857] By swapping Kdut_DEV1 and Kdut_DEV3 and swapping Kdut_DEV2 andKdut_DEV4, a pair of Kdut_DEV3 (MAC checking key of the data updateticket (DUT)) and Kdut_DEV4 (data updating encryption key) is alwaysmaintained to be newer versions than a pair of Kdut_DEV1 (MAC checkingvalue of the data update ticket (DUT)) and Kdut_DEV2 (data updatingencryption key). That is, Kdut_DUV1 and Kdut_DEV2 are keys that arenormally used, and Kdut_DEV3 and Kdut_DEV4 are keys that updateKdut_DEV1 and Kdut_DEV2, respectively, in the event of an emergency,which serve as backup keys to replace currently used Kdut_DEV1 andKdut_DEV2, respectively. This is further described below while referringto the data updating processing using the data update ticket (DUT).

[0858] The integrity-guaranteed ICV (Integrity Check Value) generatedby, for example, a data sender, during the data creation is comparedwith ICV generated based on the received data by a data receiver. If thetwo ICVs are the same, it is verified that the data has not beentampered with. If the two ICVs are different, it is determined that thedata has been tampered with. The integrity-guaranteed ICV generated by,for example, a data sender, during the data creation is stored in theICV (Integrity Check Value) field of the data update ticket (DUT), ashas been discussed in the description of the data update ticket (DUT)format in FIG. 32.

[0859] If the ICV generated by the device coincides with the ICV storedin the data update ticket-DEV (DUT(DEV)) after comparison, it isdetermined that the integrity of the ticket has been verified. If thetwo ICVs are different, it is determined that the ticket has beentampered with, and the processing using the data update ticket-DEV(DUT(DEV)) is terminated.

[0860] According to the above-described processing, the data updateticket-DEV (DUT(DEV)) checking processing when the integrity check typeindicated in the data update ticket-DEV (DUT(DEV)) is the common keysystem is completed.

[0861] If it is determined in step S523 that the ticket type is not thedata update ticket-DEV (DUT(DEV)), it is determined that the ticket isthe data update ticket-PAR (DUT(PAR)) (see FIG. 32). The data updateticket-PAR (DUT(PAR)) is the ticket used for updating the managementdata of the partition manager.

[0862] In this case, it is determined in step S529 whether the settingof the integrity check type (public key system (Public)/common keysystem (Common)) indicated in the ticket is the public key system.

[0863] If the integrity check type is the public key system, the processproceeds to step S530 in which various processings are executed. Theprocessing to be executed in step S530 is started by verifying thepublic key certificate (CERT) of the ticket issuer by using the publickey PUB CA(PAR) of the partition-manager certificate authority(CA(PAR)).

[0864] When sending the ticket issued by the data update ticket-PAR(DUT(PAR)) issuing means (DUT Issuer) to the ticket user, the public keycertificate (CERT_DUTI) of the data update ticket (DUT) issuing means(DUT Issuer) is also sent together to the device if the public keysystem is employed. The attribute of the public key certificate(CERT_DUTI) of the DUT issuing means coincides with the ticket issuingmeans code (DUTIC_PAR) recorded in PDKB(PUB) (Partition Key Definitionblock) in the device.

[0865] The signature implemented by the private key of thepartition-manager certificate authority (CA(PAR)) is added to the publickey certificate (see FIG. 11), and this signature is verified by usingthe public key PUB CA(PAR) of the partition-manager certificateauthority (CA(PAR)). The signature creation and verification isperformed according to, for example, the above-described flows shown inFIGS. 12 and 13. By this signature verification, it is determinedwhether the public key certificate (CERT) of the ticket issuer is anauthorized public key certificate (CERT) without being tampered with.

[0866] It is also determined in step S530 whether the user category coderecorded in the option area of the public key certificate (CERT), whichis verified by the signature verification, of the ticket issuing meanscoincides with the ticket issuing means code (DUTIC_PAR: DUT IssuerCategory for Partition) recorded in PKDB(PUB) (Partition Key Definitionblock) in the device.

[0867] As has been discussed in the section of the public keycertificate in FIG. 11, in the public key certificate, the category codeof the ticket issuing means (Ticket Issuer), which is the ticket (PRT,FRT, SPT, or DUT) issuing means, in this case, DUTIC (DUT Issuer Code),is recorded. By checking the consistency between the code in the optionarea and the ticket issuing means code (DUTIC: DUT Issuer Category) (seeFIG. 21) recorded in PKDB(PUB) (Partition Key Definition block) in thedevice, it is checked whether the received ticket (DUT) is the ticketissued by an authorized ticket issuing means.

[0868] The device also determines whether the ticket issuing means(Ticket Issuer) is not revoked by referring to CRL_DEV: the revocationlist (Revocation List (Certificate)), which is stored in the device keyarea (see FIG. 18) of the device memory, in which the public keycertificate identifiers (ex. serial number: SN) of the revoked devicesand the revoked units (a ticket user, such as a reader/writer or a PC,as the device access unit, or ticket issuing means) are registered.

[0869] The device also checks the signature recorded in the data updateticket-PAR (DUT(PAR)) (see FIG. 32), which is the received ticket, i.e.,the integrity check value (public key system: signature) of the ticket,and determines whether the ticket has not been tampered with. As in theabove-described signature verification of the public key certificate,the signature verification is executed according, for example, to thesequence similar to the flow in FIG. 13.

[0870] Thus, it has been checked that: (1) the public key certificate(CERT) of the ticket issuer is an authorized public key certificate(CERT) without being tampered with; (2) the code recorded in the optionarea of the public key certificate (CERT) of the ticket issuer coincideswith the ticket issuing means code (DUTIC_PAR: DUT Issuer Category forPartition) recorded in PKDB(PUB) (Partition Key Definition block) in thedevice; (3) the ticket issuing means (Ticket Issuer) is not revoked; and(4) the ticket has not been tampered with by verifying the signature ofthe received ticket (DUT). Only when all the conditions (1) through (4)are satisfied, it can be determined that the integrity of the dataupdate ticket-PAR (DUT) has been successfully verified. If any of theconditions (1) through (4) is not satisfied, it is determined that theintegrity of the data update ticket-PAR (DUT(PAR)) has not beenverified, and the processing using the data update ticket-PAR (DUT(PAR))is terminated.

[0871] If it is determined in step S529 that the integrity check type(public key system (Public)/common key system (Common)) indicated in theticket is the common key system, it is determined in step S531 whetherthe data indicated by the old data code (the code of the old data to beupdated) recorded in the data update ticket-PAR (DUT(PAR)) is Kdut_PAR1(MAC checking key of the data update ticket (DUT)) or Kdut_PAR2 (dataupdating encryption key) stored in the partition key area (see FIG. 23).

[0872] If the data indicated by the old data code (the code of the olddata to be updated) recorded in the data update ticket-PAR (DUT(PAR)) isKdut_PAR1 (MAC checking key of the data update ticket (DUT)) orKdut_PAR2 (data updating encryption key) stored in the partition keyarea (see FIG. 23), the MAC checking processing is performed in stepS533 by using Kdut_PAR3 (MAC checking key of the data update ticket(DUT)) stored in the partition key area (see FIG. 23). If the dataindicated by the old data code (the code of the old data to be updated)recorded in the data update ticket-PAR (DUT(PAR)) is not Kdut_PAR1 (MACchecking key of the data update ticket (DUT) or KPAR_DEV2 (data updatingencryption key) stored in the partition key area (see FIG. 23), the MACchecking processing is performed in step S532 by using Kdut_PAR1 (MACchecking key of the data update ticket (DUT)) stored in the partitionkey area (see FIG. 23).

[0873] The reason for using the different MAC checking keys, asdescribed above, is as follows. If the data to be updated is Kdut_PAR1(MAC checking key of the data update ticket (DUT)) or Kdut_PAR2 (dataupdating encryption key), the use of such key data is to be prohibitedfor some reason, for example, due to a leakage of key information.Accordingly, the MAC checking using such data must be avoided. The MACchecking processing is executed according to the above-describedMAC-value creation processing using the DES encryption configurationshown in FIG. 59.

[0874] The integrity-guaranteed ICV (Integrity Check Value) generatedby, for example, a data sender, during the data creation is comparedwith ICV generated based on the received data by a data receiver. If thetwo ICVS are the same, it is verified that the data has not beentampered with. If the two ICVs are different, it is determined that thedata has been tampered with. The integrity-guaranteed ICV generated by,for example, a data sender, during the data creation is stored in theICV (Integrity Check Value) field of the data update ticket (DUT), ashas been discussed in the description of the data update ticket (DUT)format in FIG. 32.

[0875] If the ICV generated by the device coincides with the ICV storedin the data update ticket-PAR (DUT(PAR)) after comparison, it isdetermined that the integrity of the ticket has been verified. If thetwo ICVs are different, it is determined that the ticket has beentampered with, and the processing using the data update ticket-PAR(DUT(PAR)) is terminated.

[0876] According to the foregoing processing, the data update ticket-PAR(DUT(PAR)) checking processing when the integrity check type indicatedin the data update ticket-PAR (DUT(PAR)) is the common key system iscompleted.

[0877] After verifying the integrity of the ticket in theabove-described processing, the process proceeds to step S541 of FIG.58. Then, the user checking, that is, the checking of the reader/writer(or a PC), which is communicating with the device, as the ticket user,which serves as the device access unit, is performed.

[0878] In step S541, the device checks the authentication flag (the flagindicating whether mutual authentication with the device is required forusing the ticket) of the received ticket (PRT, FRT, SPT, or DUT). If theflag indicates that the authentication is not required, the process iscompleted without executing the processing.

[0879] If the flag indicates that the authentication is required in theflag checking processing in step S541, the process proceeds to stepS542. In step S542, the authentication table (see FIG. 51) is checked byusing the category (group) of the ticket user (a reader/writer or a PCas the device access unit, which is to execute the processing on thedevice by using the ticket).

[0880] Subsequently, in step S543, the authentication type of thereceived ticket (data indicating the type of authentication type, i.e.,the public key authentication or the common key authentication, or anytype of authentication) is checked. If the authentication type indicates“any type”, the process proceeds to step S544 in which it is determinedwhether the mutual authentication data of the group checked in step S542is stored in the authentication table (see FIG. 51). If it is determinedthat the mutual authentication information of the corresponding group isstored in the table and that mutual authentication has been conductedbetween the ticket user (a reader/writer or a PC as the device accessunit, which is to execute the processing on the device by using theticket) and the device, it is determined that the integrity of theticket user (ex. reader/writer as the device access unit) has beenverified, i.e., that the user checking has been successfully conducted.The process is then completed. If the mutual authentication informationof the corresponding group is not stored in the authentication table(see FIG. 51), it is determined that the user checking has not beenconducted, and the process is terminated as an error.

[0881] If it is found in step S543 that the authentication type (themutual authentication type of the device (public key authentication orthe common key authentication, or any type) of the received ticket doesnot indicate “any type”, it is determined in step S545 whether theauthentication type is the public key authentication.

[0882] If the authentication type is the public key authentication, theprocess proceeds to step S546 in which the public-key mutualauthentication data of the group checked in step S542 is stored in theauthentication table (see FIG. 51). If it is determined that thepublic-key mutual authentication information of the corresponding groupis stored in the table and that mutual authentication has been conductedbetween the ticket user (a reader/writer or a PC as the device accessunit, which is to execute the processing on the device by using theticket) and the device as the public-key authentication processing, theprocess proceeds to step S547. In step S547, it is checked for thepresence of the ticket user identifier in the ticket to be processed(PRT, FRT, SPT, or DUT). If the ticket user identifier is present, it isdetermined in step S548 whether the identifier, the category, or theserial (SN) recorded as the ID data (DN) in the public key certificateof the entity to be authenticated (reader/writer as the device accessunit, which serves as the ticket user) coincides with the identifier,the category, or the serial (SN) recorded as the ID data of the ticketuser stored in the ticket. If both ID data coincide with each other, itis determined that the user checking has been successfully conducted,and the process is completed.

[0883] If it is determined in step S546 that the public-key mutualauthentication data of the group checked in step S542 is not stored inthe authentication table (see FIG. 51) and that mutual authenticationhas not been conducted between the ticket user (a reader/writer or a PCas the device access unit, which is to execute the processing on thedevice by using the ticket) and the device, it is determined that theuser checking has not been conducted, and the process is terminated asan error.

[0884] If it is determined in step S548 that the identifier, thecategory, or the serial (SN) recorded as the ID data (DN) in the publickey certificate of the entity to be authenticated (reader/writer as thedevice access unit, which serves as the ticket user) does not coincidewith the ticket user identifier stored in the ticket, it is determinedthat the ticket checking has not been conducted, and the process isterminated as an error.

[0885] If the ticket user identifier is not present in the ticket, theprocessing of step S548 is not executed, and it is determined that theuser checking has been successfully conducted, and the process iscompleted.

[0886] If it is determined in step S545 that the authentication type(the type of mutual authentication of the device (the public keyauthentication or the common key authentication, or any type)) of thereceived ticket is not the public key authentication, the processproceeds to step S549 in which it is determined whether the common-keymutual authentication data of the group checked in step S542 is storedin the authentication table (see FIG. 51). If it is determined that thecommon-key mutual authentication information of the corresponding groupis stored in the table and that mutual authentication has been conductedbetween the user ticket (a reader/writer or a PC as the device accessunit, which is to execute the processing on the device by using theticket) and the device as the common-key authentication processing, theprocess proceeds to step S550. In step S550, it is checked for theticket user identifier in the ticket to be processed (PRT, FRT, SPT, orDUT). If the ticket user identifier is present, it is determined in stepS551 whether the ID data (IDrw) of the entity to be authenticated(reader/writer as the device access unit, which serves as the ticketuser) coincides with the ticket user identifier stored in the ticket. Ifthe ID data and the ticket user identifier coincide with each other, itis determined that the user checking has been successfully conducted,and the processing is completed.

[0887] If it is determined in step S549 that the common-key mutualauthentication data of the group checked in step S542 is not stored inthe authentication table (see FIG. 51) and that mutual authenticationhas not been conducted between the ticket user (a reader/writer or a PCas the device access unit, which is to execute the processing on thedevice by using the ticket) and the device as the common-keyauthentication processing, it is determined that the user checking hasnot been conducted, and the process is terminated as an error.

[0888] If it is determined in step S551 that the ID data (IDrw) of theentity to be authenticated (reader/writer as the device access unit,which serves as the ticket user) does not coincide with the ticket useridentifier stored in the ticket, it is determined that the user checkinghas not been conducted, and the process is terminated as an error.

[0889] If the ticket user identifier is not present in the ticket, or ifall the ticket users are allowed to use the ticket, the processing ofstep S550 is not executed. It is then determined that the user checkinghas been successfully conducted, and the process is completed.

[0890] The foregoing processing is the ticket integrity and userchecking processing performed in step S413 in the flow of FIG. 47.

[0891] (Partition Creation/Deletion Processing)

[0892] Details of the partition creation/deletion processing based onthe partition registration ticket (PRT) executed in step S415 in theflow of FIG. 47 are discussed below with reference to the processingflows of FIGS. 60 and 61. The partition creation/deletion processing isthe processing executed by the device, which has received the partitionregistration ticket (PRT) from the ticket user (ex. a reader/writer or aPC as the device access unit), based on the partition registrationticket (PRT).

[0893] In step S601 of FIG. 60, the device checks the processing typerecorded in the received partition registration ticket (PRT), i.e., theoperation type (generate/delete), and determines whether a partition isto be created or deleted. If the operation type is to create apartition, step S602 and the subsequent steps are executed. If theoperation type is to delete a partition, step S621 and the subsequentsteps are executed.

[0894] The partition creation processing is first discussed. In stepS602, the device determines whether there is a partition having the samecode as the partition manager code (PMC) indicated in the partitionregistration ticket (PRT). This determination can be made by checkingwhether the same code as the description code of the received ticket(PRT) is indicated in the partition definition block (see FIG. 19) ofthe device memory.

[0895] If there is a partition having the same code (PMC) in the device,the partition creation cannot be performed since the duplication of thepartitions having the same code is not permitted, and the processing isterminated as an error. If there is no partition having the same code inthe device, in step S603, the free block number in device in the devicemanagement information block (see FIG. 15) is compared with thepartition size indicated in the partition registration ticket (PRT), andit is determined whether if there is a free block area greater than orequal to the partition size indicated in the ticket (PRT) in the devicememory. If there is no free block area greater than or equal to thepartition size, a partition having the size indicated in the PRT cannotbe created, and thus, the process is terminated as an error.

[0896] If it is determined that there is a free block area greater thanor equal to the partition size indicated in the ticket (PRT) in thedevice memory, the process proceeds to step S604. In step S604, thepointer of free area in the device management information block ischecked, and the partition definition block (PDB) area (see FIG. 19) isreserved in the uppermost block of the free area in device.

[0897] Then, the device copies the partition manager code (PMC)indicated in the partition registration ticket (PRT) into the reservedpartition definition block (PDB) area (S605), and also copies the PMCversion indicated into the PRT in the partition definition block (PDB)area (S606).

[0898] The device also copies the pointer of free area in the devicemanagement information block (see FIG. 15) into the partition startposition of the partition definition block (PDB) area (S607), and alsocopies the partition size indicated in the partition registration ticket(PRT) into the partition size of the partition definition block (PDB)area (S608).

[0899] Then, the device adds the value copied in the partition size ofthe partition definition block (PDB) area to the pointer of free area inthe device management information block (see FIG. 15) (S609), andsubtracts the partition size +1 from the free block number in device inthe device management information block (see FIG. 15) (S610), where +1means a block for the partition definition block (PDB).

[0900] Subsequently, the device adds 1, i.e., the number of createdpartition (1) to the partition number in the device managementinformation block (see FIG. 15) (S611).

[0901] Then, in step S631 of FIG. 61, the device sets the uppermostblock of the created partition area as the partition managementinformation block (PMIB) (see FIG. 20). The device also copies the PMCof the partition registration ticket (PRT) into the partition managercode (PMC) field of the set partition management information block(PMIB) (S632), copies the PMC version of the partition registrationticket (PRT) into the PMC version field of the partition managementinformation block (PMIB) (S633), and copies the partition size of thepartition registration ticket (PRT) into the field of the total blocknumber in partition of the partition management information block (PMIB)(S634).

[0902] Moreover, the device records the partition size −3 of thepartition registration ticket (PRT) in the field of the free blocknumber in partition of the partition management information block (PMIB)(S635), where −3 means that three block, such as the partitionmanagement information block (PMIB), the common-key partition keydefinition block (PKDB(common)), and the public-key partition keydefinition block (PKDB(PUB)), which are to be used, are subtracted.

[0903] The device also records 0 in the file number of the partitionmanagement information block (PMIB) (S636). At this point, there are nofiles set in the partition. The file setting can be performed by usingthe file registration ticket (FRT). The file registration processingusing the file registration ticket (FRT) is described below.

[0904] The device also copies the start position of the partitiondefinition block (PDB) into the pointer of free area of the partitionmanagement information block (PMIB), and the partition settingregistration is completed.

[0905] The partition deletion processing in steps S621 through S628 ofFIG. 60 is described below. In step S621, it is determined whether thereis a partition having the same code as the partition manager code (PMC)indicated in the partition registration ticket (PRT) in the devicememory. This determination can be made by checking whether the same codeas the description code of the received ticket (PRT) is indicated in thepartition definition block (see FIG. 19) of the device memory.

[0906] If there is no partition having the same code (PMC) in thedevice, the partition cannot be deleted, and the process is terminatedas an error. If there is a partition having the same code in the device,it is determined in step S622 whether there is a partition which iscreated after the partition to be deleted. If there is no partitioncreated after the partition to be deleted, the partition to be deletedis the latest partition, and the partition definition block (PDB) (seeFIG. 19) of the target partition is deleted in step S629.

[0907] If it is determined in step S622 that there is a partition whichis created after the partition to be deleted in the device, the data ofthe later partition is displaced to the lower side by the size of thepartition (PS) to be deleted (S623), and the partition definition block(PDB) of the later partition is displaced to the upper side by one block(S624). Moreover, the size of the partition to be deleted (PS) issubtracted from the partition start position recorded in the partitiondefinition block (PDB) of the later partition (S625).

[0908] After the processing of step S625 or S629, in step S626, the sizeof the partition to be deleted (PS) +1 is added to the free block numberin device of the device management information block (DMIB) (see FIG.15), where +1 means a block for the partition definition block of thepartition to be deleted.

[0909] Subsequently, in step S627, the size of the partition to bedeleted (PS) is subtracted from the value of the pointer of free area inthe device management information block (see FIG. 15). In step S628, 1,i.e., the number of deleted partition (1), is subtracted from thepartition number of the device management information block (see FIG.15), and then, the partition deletion processing based on the partitionregistration ticket (PRT) is completed.

[0910] The foregoing processing is the partition creation/deletionprocessing based on the partition registration ticket (PRT) in step S415of the processing flow of FIG. 47.

[0911] (Partition Initial Registration)

[0912] A description is now given, with reference to the flow of FIG. 62and the subsequent drawings, of details of the partition initial datawriting processing in step S406 or S419 of the processing flow of FIG.47, that is, the partition initial registration processing based on thepartition registration ticket (PRT).

[0913] In the processing flows of FIGS. 62, 63, and 64, the processingof the initial registration managed by the partition manager is shown atthe left side, and the processing of the device (see FIG. 5) is shown atthe right side. The initial registration unit managed by the partitionmanager is the unit (ex. a reader/writer or a PC as the device accessunit) that can read and write data from and into the device, and has theconfiguration corresponding to the reader/writer as the device accessunit shown in FIG. 10. As indicated in the processing flow of FIG. 47,it is assumed that, before the start of the processing in FIG. 62,mutual authentication has been conducted between the initialregistration unit and the device, and that the integrity of the ticketand the user (for example, a reader/writer as the device access unit,which serves as the ticket user) has been verified in the user checking,and that the partition creation processing based on the partitionregistration ticket (PRT) has been completed. In the data sending andreceiving between the initial registration unit and the device shown inFIGS. 62, 63, and 64, data encrypted by using the session key Ksescreated in the mutual authentication is sent and received.

[0914] In step S641 of FIG. 62, the initial registration unit determineswhether the common key is used for partition authentication. Thisdetermination can be made by checking the field of the mutualauthentication type (the public key authentication, the common keyauthentication, or any type) of the device of the partition registrationticket (PRT) (see FIG. 26) to be used.

[0915] As shown in FIG. 62, if the common key is used for partitionauthentication, steps S642 and 643 and steps S651 through S654 areexecuted, and if the common key is not used for partitionauthentication, these steps are skipped.

[0916] If the common key is used for partition authentication, in stepS642, the initial registration unit sends a common-key authenticationdata write command, such as MKauth_PAR_A: the two-way individual keyauthentication master key, Kauth_PAR_B: the two-way individual keyauthentication common key, IRL_PAR: the revocation list (Revocation List(Device ID)) in which the device identifiers (IDs) of the revokeddevices are registered, and version information thereof to the device.

[0917] Upon receiving the above-mentioned write command in step S651,the device writes the received data into the partition key area (seeFIG. 23) in step S652. Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing (S653), and sends a write completionmessage to the registration unit (S654).

[0918] Upon receiving the write completion message (S643), theregistration unit determines in step S644 whether the public key is usedfor partition authentication As shown in FIG. 62, if the public key isused for partition authentication, steps S645 through 649 and steps S655through S662 are executed. If the public key is not used for partitionauthentication, these steps are omitted.

[0919] When the public key is used for partition authentication, in stepS645, the registration unit sends a public-key authentication data writecommand, such as PUB_CA(PAR): the public key of the certificateauthority CA(PAR) that issues the partition-manager public keycertificate, PARAM_PAR: the pubic key parameter of the partition,CRL_PAR: the revocation list (Revocation List (Certificate) in which thepublic key certificate identifiers (ex. serial number: SN) of therevoked devices are registered, and version information thereof to thedevice.

[0920] Upon receiving the above-mentioned write command in step S655,the device writes the received data into the partition key area (seeFIG. 23) in step S656. Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing (S657), and sends a write completionmessage to the registration unit (S658).

[0921] Upon receiving the write completion message (S646), theregistration unit sends a key-pair creation command for creating apublic key and a private key to the device (S647). In this embodiment,the device creates a key pair. However, the registration unit may createa key pair and send it to the device.

[0922] Upon receiving the key-pair creation command (S659), the devicecreates a pair of a public key (PUB PAR) and a private key (PRI PAR) byusing the encryption processor (see FIG. 5) in the device, and writesthe created keys into the partition key area (see FIG. 23) (S660). Then,the device makes adjustments of the pointer, the size, and the freeblock number in device, which are required due to the data writing(S661), and sends the created and stored public key to the registrationunit (S662).

[0923] The registration unit receives the public key (PUB PAR) from thedevice (S648), and stores it in the database (DB(PAR)) (see FIG. 9)within the partition manager, together with the device identifier IDmpreviously received from the device.

[0924] The registration unit of the partition manager then determineswhether the common key is used for verifying the file registrationticket (FRT) (S671). As described above, ticket verification can beperformed according to the common key system by using the MAC valuechecking or the public key system in which the signature is created bythe private key and is verified by the public key. The partition manageris able to set the verification type to be used by the device. Thepartition manager sets data for implementing the common key or thepublic key or data for implementing either key in the device accordingto the FRT ticket verification type employed by the device.

[0925] If the common key authentication is employed for verifying thefile registration ticket (FRT), the partition manager sets informationrequired for FRT verification using the common key system (ex.FRT-verification common key). If the device does not execute the commonkey authentication, the partition manager does not store suchinformation in the device.

[0926] As shown in FIG. 63, if the common key system is used for FRTverification, steps S672 and 673 and steps S681 through S684 areexecuted, and if the common key is not used for FRT verification, thesesteps are skipped.

[0927] If the common key is used for FRT verification, in step S672, theregistration unit sends an FRT-verification common key write command,such as Kfrt: the MAC checking key of the file registration ticket (FRT)and version information thereof to the device.

[0928] Upon receiving the above-mentioned write command in step S681,the device writes the received data into the partition key area (seeFIG. 23) in step S682. Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing, (S683), and sends a write completionmessage to the registration unit (S684).

[0929] Upon receiving the write completion message (S673), theregistration unit determines in step S674 whether the public key is usedfor FRT verification. As shown in FIG. 63, if the public key is used forFRT verification, steps S675 and 676 and steps S685 through S690 areexecuted, and if the public key is not used for FRT verification, thesesteps are skipped.

[0930] If the public key is used for FRT verification, in step S675, theregistration unit sends an FRT-verification data write command, such asFRTIC (FRT Issuer Category): the file registration ticket (FRT) issuercategory, PUB_CA(PAR): the public key of the certificate authorityCA(PAR) that issues the partition-manager public key certificate,PARAM_PAR: the public key parameter of the partition, CRL_PAR: therevocation list (Revocation List (Certificate)) in which the public keycertificate identifiers (ex. serial number: SN) of the revoked devicesare registered, and version information thereof to the device.

[0931] The device receives the above-mentioned write command in stepS685, and in step S686, the device writes FRTIC (FRT Issuer Category):the file registration ticket (FRT) issuer category in the received datainto the public-key partition key definition block (PKDB(PUB)) (see FIG.22), and writes the version information into the version area of thesame block.

[0932] Then, the device determines in step S687 whether PUB_CA(PAR): thepublic key data of the certificate authority CA(PAR) that issues thepartition-manager public key certificate has been written. IfPUB_CA(PAR) has not been written, PUB_CA(PAR), PARAM_PAR, and CRL_PARare written into the partition key area (see FIG. 23) in step S688. Thedevice then makes adjustments of the pointer, the size, and the freeblock number in device, which are required due to the data writing,(S689), and sends a write completion message to the registration unit(S690).

[0933] Upon receiving the write completion message (S676), theregistration unit determines in step S701 whether the updating of thecommon key data is supported. Among the data stored in the device, partof the data can be updated by using the above-described data updateticket (DUT) (see FIG. 32). The data that can be updated has beendiscussed with reference to FIG. 33. Either the common key system or thepublic key system can be used for the updating processing using the dataupdate ticket (DUT). The partition manager sets data for implementingthe public key system or the common key system or data for implementingeither type in the device according to the set partition.

[0934] If the set partition is configured such that the data can beupdated according to the common key system, the partition manager setsinformation required for updating the data according to the common keysystem (ex. the MAC checking key of the data update ticket (DUT)) in thepartition key area of the device. If the device does not execute thecommon key authentication, the partition manager does not set suchinformation in the partition key area.

[0935] As shown in FIG. 64, if the common key system is used forupdating the data using the data update ticket (DUT), steps S702 and 703and steps S711 through S714 are executed, and if the common key systemis not used for updating the data, these steps are skipped.

[0936] If the common key is used for updating the data, in step S702,the registration unit sends a data update ticket (DUT)-verificationcommon key write command, such as Kdut_PAR1: the MAC checking key of thedata update ticket (DUT), Kdut_PAR2: the data updating encryption key,Kdut_PAR3: the MAC checking key of the data update ticket (DUT),Kdut_PAR4: the data updating encryption key, and version informationthereof to the device.

[0937] Upon receiving the above-mentioned write command in step S711,the device writes the received data into the partition key area (seeFIG. 23) in step S712. Then, the device makes adjustments of thepointer, the size, and the free block number in device, which arerequired due to the data writing (S713), and sends a write completionmessage to the registration unit (S714).

[0938] Upon receiving the write completion message (S703), theregistration unit determines in step S704 whether the partition set inthe device is configured such that the data updating using the dataupdate ticket (DUT) according to the public key system can be supported.As shown in FIG. 64, if the public key system is supported, steps S705and 706 and steps S715 through S718 are executed, and if the public keysystem is not supported, these steps are skipped.

[0939] If the public key system is supported, in step S705, theregistration unit sends a data update ticket (DUT) issuer code writecommand, such as DUTIC_PAR (DUT Issuer Category): the data update ticket(DUT) issuer category, and version information to the device.

[0940] The device receives the above-described write command instep,S715, and writes the received data into the public-key partitionkey definition block (PKDB(PUB)) in step S716. The device then makesadjustments of the pointer, the size, and the free block number indevice, which are required due to the data writing (S717), and sends awrite completion message to the registration unit (S718). Theregistration unit receives the write completion message (S706), and theprocess is then completed.

[0941]FIG. 65 illustrates an example of the data configuration stored inthe memory device when the initial registration processing (theprocessing flows of FIGS. 62 through 64) by the partition manager isfinished. In the partition area shown in FIG. 65, the following data aresent from the registration unit and are generated by the device andwritten in the partition key area in the flows (FIGS. 62 through 64):

[0942] IRL_PAR: the revocation list (Revocation List (Device ID)) inwhich the identifiers (IDs) of the revoked devices and the revoked units(a ticket user, such as a reader/writer or a PC, as the device accessunit, or ticket issuing means) are registered;

[0943] CRL_PAR: the revocation list (Revocation List (Certificate)) inwhich the public key certificate identifiers (ex. serial number: SN) ofthe revoked devices and the revoked units (a ticket user, such as areader/writer or a PC, as the device access unit, or ticket issuingmeans) are registered;

[0944] Kauth_PAR_B: the two-way individual key authentication commonkey;

[0945] Mkauth_PAR_A: the two-way individual key authentication masterkey;

[0946] Kdut_PAR1: the MAC checking key of the data update ticket (DUT);

[0947] Kdut_PAR2: the data updating encryption key;

[0948] Kdut_PAR3: the MAC checking key of the data update ticket (DUT);

[0949] Kdut_PAR4: the data updating encryption key;

[0950] Kfrt: the MAC checking key of the file registration ticket (FRT);

[0951] PUB_PAR: the public key of the partition; and

[0952] PRI_PAR: the private key of the partition.

[0953] The following data of the partition management information blockare written during the partition creation (see the processing flows ofFIGS. 60 and 61):

[0954] PARAM_PAR: the public key parameter of the partition;

[0955] PUB_CA(PAR): the public key of the certificate authority CA(PAR);and

[0956] the data in the common-key partition key information block(Partition Key Definition Block (Common)), and the public-key partitionkey information block (Partition Key Definition Block(PUB)).

[0957] [B4.2. Public Key Certificate Issuing Processing Under PartitionManger Control]

[0958] The issuing processing of the partition public key certificate bythe partition manager is discussed below with reference to FIG. 66 andthe subsequent drawings. In the device, the device public keycertificate (CERT DEV) used for authenticating the entire device andperforming the processing based on the device, and the partition publickey certificate (CERT PAR) used for authenticating a specific partitionin the device and for verifying the processing are stored. The partitionpublic key certificate (CERT PAR) can be set for each partition set inthe device.

[0959] The partition public key certificate (CERT PAR) is issued by aprocedure for providing the public key certificate issued by thecertificate authority (CA for PM) (see FIGS. 2 and 3) to the device viathe registration authority managed by the partition manager. Theregistration authority manages the public key certificate (CERT PAR)issued by the registration authority managed by the partition manager(database 332 (see FIG. 9)).

[0960] The procedure for issuing the partition public key certificate(CERT PAR) to the set partition by the registration authority managed bythe partition manager is described below with reference to FIGS. 66 and67. In FIGS. 66 and 67, the processing of the CERT (public keycertificate) issuing unit of the registration authority managed by thepartition manager, and more specifically, the processing of the controlmeans 331 of the partition manager shown in the diagram of FIG. 9, isshown at the left side, and the processing of the device is shown at theright side.

[0961] In step S721, the CERT issuing unit first obtains userinformation of the device to which the partition public key certificate(CERT PAR) is to be issued, permits (determines) the issuing of thecertificate, and ensures a communication channel with the target device.The user information of the device to which the partition public keycertificate (CERT PAR) is to be issued can be obtained by, for example,the data generated in the device initial registration. The userinformation may be obtained from the device after a communicationchannel with the device is set. The communication channel may be a cableor wireless communication channel through which the data can be sent andreceived.

[0962] Then, in step S722, the CERT issuing unit sends anauthentication-data creation command containing a random number R to thedevice. Upon receiving the authentication-data creation command (S731),the device generates a digital signature (S) by applying the deviceprivate key (PRI PAR) to the data consisting of the received randomnumber R and the device identifier (IDm) (S732) (see FIG. 12). Thedevice then sends the ID data (IDm) and the signature (S) of the deviceto the CERT issuing unit.

[0963] Upon receiving the ID data (IDm) and the signature (S) from thedevice (S723), the CERT issuing unit obtains the device public key (PUBPAR) from the database DB(PAR) 332 by using the received device ID data(IDm) as the search key. The CERT issuing unit also verifies thesignature (S) by applying the obtained device public key (PUB PAR) (seeFIG. 13) (S725). If the verification has not succeeded, it is determinedthat the data sent from the device is unauthorized data, and the processis terminated.

[0964] If the verification has succeeded, the CERT issuing unit requeststhe certificate authority (CA for PM) 620 to issue the partition publickey certificate (CERT PAR) (S727). The partition manager receives thepartition public key certificate (CERT PAR) issued by the certificateauthority 620 (S728), and sends it to the device (S729).

[0965] Upon receiving the partition public key certificate (CERT PAR)from the partition manager (registration authority), the device verifiesthe signature of the received partition public key certificate (CERTPAR) by using the public key (PUB CA(PAR)) of the certificate authority,which is stored in the partition key area (see FIG. 23). That is, thesignature (see FIG. 11) implemented by the private key of thecertificate authority is added to the public key certificate, and thissignature is verified (S735)

[0966] If the signature verification has failed, it is determined thatthe public key certificate is not an authorized public key certificate,and an error message is sent to the CERT issuing unit (S745).

[0967] If the signature verification has succeeded, the device publickey (PUB PAR) stored in the partition public key certificate (CERT PAR)is compared with the device public key (PUB PAR) stored in the device(S741). If the two public keys do not coincide with each other, an errormessage is sent. If the two public keys coincide with each other, thereceived partition public key certificate (CERT PAR) is stored in thepartition key area (see FIG. 23) (S743). Before the issuing of thepartition public key certificate (CERT PAR), the public key (PUB PAR)generated by the device is stored in this area, and when the authorizedpartition public key certificate (CERT PAR) is issued, the public key(PUB PAR) is replaced by the partition public key certificate (CERTPAR).

[0968] Upon completing the storage of the partition public keycertificate (CERT PAR), a storage completion message is sent to the CERTissuing unit (S744). Upon receiving the storage completion message(S751), the CERT issuing unit determines whether the storage processinghas been successfully finished (S752), and the process is thencompleted. If it is determined that the storage processing has not beensuccessfully finished, the process is terminated as an error.

[0969] [B4.3. Processing Procedure in Each Partition Creation ProcessingMethod]

[0970] As described above, in the partition setting registrationprocessing, mutual authentication is conducted between the device andthe reader/writer as the device access unit managed by the partitionmanager, and the partition setting is performed based on the partitionregistration ticket (PRT). As discussed above, there are two types ofmutual authentication modes, i.e., the public key mutual authenticationand the common key mutual authentication. As the ticket (PRT)verification, the signature verification of the public key system or theMAC checking of the common key system is performed. That is, thefollowing four processing modes are provided:

[0971] (A) mutual authentication (public key) and ticket (PRT)verification (public key);.

[0972] (B) mutual authentication (public key) and ticket (PRT)verification (common key);

[0973] (C) mutual authentication (common key) and ticket (PRT)verification (common key); and

[0974] (D) mutual authentication (common key) and ticket (PRT)verification (public key).

[0975] The four processing modes are briefly discussed with reference tothe drawings by emphasizing the data transfer processing executed amongthe entities, such as the certificate authority (CA(DM)), the devicemanager (DM), the partition manager (PM), and the device.

[0976] (A) Mutual Authentication (Public Key) and Ticket (PRT)Verification (Public Key)

[0977] A description is first given, with reference to FIG. 68, of thedata transfer performed among the entities when the public key system isused for mutual authentication processing and the public key system isused for ticket (PRT) verification. For the sake of simplicity, as shownin FIG. 68, a single certificate authority (CA) is provided, a singleregistration authority is provided in the device manager, and thedevice-manager public key certificate (Cert. DM) and thepartition-manager public key certificate (Cert. PM) are issued by theregistration authority and the certificate authority. The device manager(DM) serves as the partition registration ticket (PRT) issuing means,and the signature of the partition registration ticket (PRT) isimplemented by the private key of the device manager.

[0978] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 68. The processing is described belowaccording to the numbers.

[0979] (1) Issuing of Public Key Certificate (Cert. DM) of DeviceManager (DM)

[0980] In response to a request from the device manager, the public keycertificate (Cert. DM) is issued by the certificate authority for thedevice manager according to a certificate issuing procedure via theregistration authority.

[0981] (2) Issuing of Public Key Certificate (Cert. PM) of PartitionManager (PM)

[0982] In response to a request from the partition manager, the publickey certificate (Cert. PM) is issued to the partition manager by thecertificate authority (CA) according to a certificate issuing procedurevia the registration authority.

[0983] (3) Issuing Processing of Partition Registration Ticket (PRT)

[0984] The partition registration ticket (PRT) is issued to thepartition manager (PM) by the partition registration ticket (PRT)issuing means (PRT Ticket Issuer) managed by the device manager. In thiscase, for creating and verifying the public-key signature, the signatureis created by the private key of the device manager (see FIG. 12), andis added to the PRT.

[0985] (4) Supply of PRT and DM Public Key Certificate (Cert. DM) to PM

[0986] The partition registration ticket (PRT) issued by the partitionregistration ticket issuing means (PRT Ticket Issuer) managed by thedevice manager is supplied to the partition manager together with the DMpublic key certificate (Cert. DM).

[0987] (5) Mutual Authentication Between PM and Device

[0988] The public-key mutual authentication (see FIG. 50) is performedbetween the device, which is to generate a partition according to theissued PRT, and the partition manager (and more specifically, areader/writer as the device access unit, which serve as a ticket user).

[0989] (6) Supply of PRT and DM Public Key Certificate (Cert. DM) toDevice

[0990] After the mutual authentication has been successfully conductedbetween the PM and the device, the partition manager (PM) sends thepartition registration ticket (PRT) and the DM public key certificate(Cert. DM) to the device.

[0991] The device has checked the following factors concerning thereceived partition registration ticket (PRT): (1) the public keycertificate (CERT) of the ticket issuer (DM) is an authorized public keycertificate (CERT) without being tampered with; (2) the code recorded inthe option area of the public key certificate (CERT) of the ticketissuer coincides with the ticket issuing means code (PRTTC: PRT IssuerCode) recorded in the device DKDB (Device Key Definition Block) (PUB);(3) the ticket issuing means (Ticket Issuer) is not revoked; and (4) theticket has not been tampered with by verifying the signature of thereceived ticket (PRT). The PRT user (PM: a reader/writer as the deviceaccess unit) is also verified (see FIGS. 57 and 58) by checking whetherthe identifier, the category, or the serial (SN) of the PRT user (inthis case, PM: a reader/writer as the device access unit, which servesas a ticket user) stored in the PRT ticket coincides with theidentifier, the category, or the serial (SN) recorded as the ID data(DN) of the partition-manager public key certificate to check thatmutual authentication has been conducted.

[0992] (7) Creation of Partition

[0993] After the verification of the partition registration ticket (PRT)and the verification of the PRT issuer and the PRT user have succeeded,a partition is created in the device memory according to the rulesindicated in the partition registration ticket (PRT) (see FIGS. 60 and61).

[0994] (8) Writing of Key Data

[0995] After creating the partition in the device memory, various keysare stored in the created partition.

[0996] (9) Reading of Public Key

[0997] (10) Issuing of Public Key Certificate

[0998] If the public key system is used for performing authentication(for using the services, such as partition creation, file creation, fileaccess, and data updating), the device creates a key pair of a publickey and a private key, sends the created public key to the partitionmanager, issues the public key certificate via the registrationauthority and the certificate authority, and stores the issued publickey certificate in the partition key area (see FIG. 23). In this case,the public key certificate issued for the storage area of the createdpublic key is stored. Steps (9) and (10) are executed when the publickey system is employed for performing authentication on the createdpartition for the use of various services (partition creation, filecreation, file access, data updating, etc.).

[0999] By performing the above-described processing, the partitioncreation processing in accordance with the mutual authentication (publickey) and ticket (PRT) verification (public key) can be executed.

[1000] (B) Mutual Authentication (Public Key) and Ticket (PRT)Verification (Common Key)

[1001] The data transfer performed among the entities when the publickey system is applied to the mutual authentication processing and thecommon key system is applied to the ticket (PRT) verification isdescribed below with reference to FIG. 69. The data transfer isperformed among the entities in the order of the numbers shown in FIG.69. The processing is discussed below according to the numbers.

[1002] (1) Public Key Certificate (Cert. PM) of Partition Manager (PM)

[1003] In response to a request from the partition manager, the publickey certificate (Cert. PM) is issued to the partition manager by thecertificate authority (CA) according to a certificate issuing procedurevia the registration authority.

[1004] (2) Issuing Processing of Partition Registration Ticket (PRT)

[1005] In response to a request from the partition manager, thepartition registration ticket (PRT) is issued to the partition manager(PM) by the partition registration ticket issuing means (PRT TicketIssuer) managed by the device manager. In this case, the MAC (MessageAuthentication Code) (see FIG. 59) is added to the PRT as the common-keyverification value.

[1006] (3) Supply of PRT to PM

[1007] The partition registration ticket (PRT) issued by the partitionregistration ticket issuing means (PRT Ticket Issuer) managed by thedevice manager is supplied to the partition manager.

[1008] (4) Mutual Authentication Between PM and Device

[1009] The public-key mutual authentication (see FIG. 50) is performedbetween the device, which is to generate a partition according to theissued PRT, and the partition manager (and more specifically, areader/writer as the device access unit, which serve as a ticket user).

[1010] (5) Sending of PRT

[1011] The partition manager sends the issued partition registrationticket (PRT) to the device. The device performs MAC verification for thereceived partition registration ticket (PRT), and verifies the PRTissuer. The device also verifies the PRT user (PM: a reader/writer asthe device access unit) (see FIGS. 57 and 58) by checking whether theidentifier, the category, or the serial (SN) of the PRT user (in thiscase, PM: a reader/writer as the device access unit, which serves as aticket user) stored in the PRT ticket coincides with the identifier, thecategory, or the serial (SN) recorded as the ID data (DN) of thepartition-manager public key certificate to determine that mutualauthentication has been conducted.

[1012] (6) Creation of Partition

[1013] After the verification of the partition registration ticket (PRT)and the verification of the PRT issuer and the PRT user have succeeded,a partition is created in the device memory according to the rulesindicated in the partition registration ticket (PRT) (see FIGS. 60 and61).

[1014] (7) Writing of Key Data

[1015] After creating the partition in the device memory, various keysare stored in the created partition.

[1016] (8) Reading of Public Key

[1017] (9) Issuing of Public Key Certificate

[1018] If the public key system is employed for performingauthentication on the created partition (for the use of services, suchas partition creation, file creation, file access, and data updating),the device creates a key pair of a public key and a private key, sendsthe created public key to the partition manager, issues the public keycertificate via the registration authority and the certificateauthority, and stores the issued public key certificate in the partitionkey area (see FIG. 23). In this case, the public key certificate issuedfor the storage area of the created public key is stored. Steps (8) and(9) are executed when the public key system is employed for performingauthentication on the created partition for the use of various services(partition creation, file creation, file access, data updating, etc.).

[1019] By performing the above-described processing, the partitioncreation processing according to the mutual authentication (public key)and ticket (PRT) verification (common key) can be executed.

[1020] (C) Authentication Processing (Common Key) and Ticket (PRT)Verification (Common Key)

[1021] The data transfer performed among the entities when the commonkey system is applied to the mutual authentication processing and thecommon key system is applied to ticket (PRT) verification is describedbelow with reference to FIG. 70. The data transfer is performed amongthe entities in the order of the numbers indicated in FIG. 70. Theprocessing is described according to the numbers.

[1022] (1) Issuing Processing of Partition Registration Ticket (PRT)

[1023] The partition registration ticket (PRT) is issued to thepartition manager (PM) by the partition registration ticket issuingmeans (PRT Ticket Issuer) managed by the device manager. In this case,the MAC (see FIG. 59) is added to the PRT as the common-key verificationvalue.

[1024] (2) Supply of PRT to PM

[1025] The partition registration ticket (PRT) issued by the partitionregistration ticket issuing means (PRT Ticket Issuer) managed by thedevice manager is sent to the partition manager.

[1026] (3) Mutual Authentication Between PM and Device

[1027] The common-key mutual authentication (see FIGS. 53 and 54) isperformed between the device, which is to create a partition accordingto the issued PRT, and the partition manager (and more specifically, areader/writer as the device access unit, which serves as a ticket user).

[1028] (4) Sending of PRT

[1029] The partition manager sends the issued partition registrationticket (PRT) to the device. The device performs MAC checking processingfor the received partition registration ticket (PRT), verifies the PRTissuer, and also verifies the PRT user (PM: a reader/writer as thedevice access unit) (see FIGS. 57 and 58) by checking the consistencybetween the identifier of the PRT user (in this case, PM: areader/writer as the device access unit, which serves as a ticket user)stored in the PRT ticket and the identifier of the partition manager tocheck whether the mutual authentication has been conducted.

[1030] (5) Creation of Partition

[1031] After the verification of the partition registration ticket (PRT)and the verification of the PRT issuer and the PRT user have succeeded,a partition is created in the device memory according to the rulesindicated in the partition registration ticket (PRT) (see FIGS. 60 and61).

[1032] (6) Writing of Key Data

[1033] After creating the partition in the device memory, various keysare stored in the created partition.

[1034] (7) Reading of Public Key

[1035] (8) Issuing of Public Key Certificate

[1036] If the public key system is employed for performingauthentication for the use of services (partition creation, filecreation, file access, and data updating), the device creates a key pairof a public key and a private key, sends the created public key to thepartition manager, issues the public key certificate via theregistration authority and the certificate authority, and stores theissued public key certificate in the partition key area (see FIG. 23).In this case, the public key certificate issued for the storage area ofthe created public key is stored. Steps (7) and (8) are executed whenthe public key system is employed for performing authentication on thecreated partition for the use of various services (partition creation,file creation, file access, data updating, etc.).

[1037] By performing the above-described processing, the partitioncreation processing according to the mutual authentication (common key)and ticket (PRT) verification (public key) is executed.

[1038] (D) Mutual Authentication (Common Key) and Ticket (PRT)Verification (Public Key)

[1039] The data transfer performed among the entities when the commonkey system is applied to the mutual authentication processing and thepublic key system is applied to the ticket (PRT) verification isdescribed below with reference to FIG. 71. The data transfer isperformed among the entities in the order of the numbers shown in FIG.71. The processing is described below according to the numbers.

[1040] (1) Issuing of Public Key Certificate (Cert. DM) of DeviceManager (DM)

[1041] In response to a request from the device manager, the public keycertificate (Cert. DM) is issued to the device manager by thecertificate authority (CA) according to a certificate issuing procedurevia the registration authority.

[1042] (2) Issuing Processing of Partition Registration Ticket (PRT)

[1043] The partition registration ticket (PRT) is issued to thepartition manager (PM) by the partition registration ticket issuingmeans (PRT Ticket Issuer) managed by the device manager. In this case,for creating and verifying a public-key signature, a signature iscreated by the private key of the device manager (see FIG. 12) and isadded to the PRT.

[1044] (3) Supply of PRT and DM Public Key Certificate (Cert. DM) to PM

[1045] The partition registration ticket (PRT) issued by the partitionregistration ticket issuing means (PRT Ticket Issuer) managed by thedevice manager is sent to the partition manager together with the DMpublic key certificate (Cert. DM).

[1046] (4) Mutual Authentication Between PM and Device

[1047] The common-key mutual authentication (see FIGS. 53 and 54) isperformed between the device, which is to create a partition accordingto the issued PRT, and the partition manager (and more specifically, areader/writer as the device access unit, which serves as a ticket user).

[1048] (5) Supply of PRT and DM Public Key Certificate (Cert. DM) toDevice

[1049] After the mutual authentication has been successfully conductedbetween the PM and the device, the partition manager (PM) sends thepartition registration ticket (PRT) and the DM public key certificate(Cert. DM) to the device.

[1050] The device has checked the following factors concerning thereceived partition registration ticket (PRT): (1) the public keycertificate (CERT) of the ticket issuer (DM) is an authorized public keycertificate (CERT) without being tampered with; (2) the code recorded inthe option area of the public key certificate (CERT) of the ticketissuer coincides with the ticket issuing means code (PRTIC: PRT IssuerCode) recorded in the device DKDB (Device Key Definition Block)(PUB);(3) the ticket issuing means (Ticket Issuer) is not revoked; and (4) theticket has not been tampered with by verifying the signature of thereceived ticket (PRT). The PRT user (PM: a reader/writer as the deviceaccess unit) is also verified (see FIGS. 57 and 58) by checking whetherthe identifier, the category, or the serial (SN) of the PRT user (inthis case, PM: a reader/writer as the device access unit, which servesas a ticket user) stored in the PRT ticket coincides with theidentifier, the category, or the serial (SN) recorded as the ID data(DN) of the partition-manager public key certificate to check thatmutual authentication has been conducted.

[1051] (6) Creation of Partition

[1052] After the verification of the partition registration ticket (PRT)and the verification of the PRT issuer and the PRT user have succeeded,a partition is created in the device memory according to the rulesindicated in the partition registration ticket (PRT) (see FIGS. 60 and61).

[1053] (7) Writing of Key Data

[1054] After creating the partition in the device memory, various keysare stored in the created partition.

[1055] (8) Reading of Public Key

[1056] (9) Issuing of Public Key Certificate

[1057] If the public key system is employed for performingauthentication on the created partition for the use of services(partition creation, file creation, file access, and data updating), thedevice creates a key pair of a public key and a private key, sends thecreated public key to the partition manager, issues the public keycertificate via the registration authority and the certificateauthority, and stores the issued public key certificate in the partitionkey area (see FIG. 23). In this case, the public key certificate issuedfor the storage area of the created public key is stored. Steps (8) and(9) are executed when the public key system is employed for performingauthentication on the created partition for the use of various services(partition creation, file creation, file access, data updating, etc.).

[1058] By performing the above-described processing, the partitioncreation processing according to the mutual authentication (common key)and ticket (PRT) verification (public key) is executed.

[1059] [B4.4. File Creation and Deletion Processing Using FileRegistration Ticket (FRT)]

[1060] A description is now given, with reference to the flow of FIG. 72and the subsequent drawings, of the processing for creating or deletinga file in the partition generated in the device by applying the fileregistration ticket (FRT). The file creation/deletion processingincludes mutual authentication processing (device authentication orpartition authentication) between the device and the reader/writer(partition manager) as the device access unit and integrity verificationprocessing of the partition registration ticket (FRT).

[1061] The file creation/deletion flow in FIG. 72 is described below. InFIG. 72, the processing of the file creation/deletion unit of thepartition manager is shown at the left side, and the processing of thedevice (see FIG. 5) is shown at the right side. The filecreation/deletion unit of the partition manager is a unit that can readand write data from and into the device (ex. a reader/writer or a PC asthe device access unit) and corresponds to the reader/writer as thedevice access unit shown in FIG. 10. An overview of the filecreation/deletion processing is discussed below with reference to FIG.72, and then, details of the file creation/deletion processing includedin the processing shown in FIG. 72 is discussed with reference to theflow of FIG. 73.

[1062] First, in steps S801 and S810 of FIG. 72, the mutualauthentication processing is performed between the filecreation/deletion unit and the device. Between the two means forperforming data sending and receiving, it is first checked with eachother whether they are authorized data communication means, and then,data transfer is performed according to the necessity. The mutualauthentication processing is to check whether the other party isauthorized data communication means. In the mutual authenticationprocessing, a session key is created, and data is encrypted by using thesession key as the common key. Then, the data is transferred. As

[1063] As the mutual authentication processing, the partitionauthentication is performed, as has been discussed in the section of thepartition creation/deletion processing. A common key system or a publickey system is used for the file creation/deletion processing. The mutualauthentication is similar to the processing discussed with reference toFIGS. 48 through 56, and an explanation thereof is thus omitted.

[1064] The processing to be executed as the mutual authenticationprocessing is determined by:

[1065] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket; and

[1066] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device; of the file registration ticket (FRT) (see FIG. 27) to beused.

[1067] If the authentication processing has failed (No in steps S802 andS811), it means that it cannot be verified that the two means areauthorized device and unit. Accordingly, the subsequent processing isnot executed, and the process is terminated as an error.

[1068] If the authentication processing has succeeded, the filecreation/deletion unit sends the file registration ticket (FRT) to thedevice. The file registration ticket (FRT) is the ticket issued by thefile registration ticket (FRT) issuing means (FRT Issuer) managed by thepartition manager. The file registration ticket (FRT) is the accesscontrol ticket for the device, and has the above-described data formatconfiguration shown in FIG. 27.

[1069] When the file registration ticket (FRT) is sent to the ticketuser, the public key certificate (CERT_FRTI) of the file registrationticket (FRT) issuing means (FRT Issuer) is also sent together if thepublic key system is employed. The attribute of the public keycertificate (CERT_FRTI) of the FRT issuing means coincides with theidentifier (FRTIC) of the file registration ticket (FRT) issuing means(FRT User).

[1070] Upon receiving the file registration ticket (FRT) (S812), thedevice verifies the integrity of the ticket (FRT) and also checks theuser (S813). The integrity verification processing of the ticket isperformed by using the MAC checking of the common key system or thesignature verification processing of the public key system. The userchecking is performed by verifying the integrity of the entity (ticketuser) that has sent the ticket, and, after the mutual authentication hassucceeded, it is determined whether the ID data of the entity and theticket user identifier (see FIG. 27) recorded in the ticket coincidewith each other. These processings are similar to the processings usingthe partition registration ticket (PRT) discussed with reference toFIGS. 57 through 59, and an explanation thereof is thus omitted.

[1071] In the device, if the integrity of the received ticket (FRT) andthe authenticity of the user cannot be successfully verified (No inS814), a file registration ticket (FRT) reception error is reported tothe file creation/deletion unit (S818). If the integrity of the ticketand the authenticity of the user are verified (Yes in S814), a file iscreated or deleted in the device memory according to the rules indicatedin the received file registration ticket (FRT). Details of thisprocessing are discussed below by using a different flow.

[1072] If the file creation/deletion processing has succeeded accordingto the description of the file registration ticket (FRT) (Yes in S816),it is reported to the file creation/deletion unit that the FRT receptionhas succeeded (S817). If the file creation/deletion processing hasfailed (No in S816), an FRT reception error is reported to the filecreation/deletion unit (S818).

[1073] The file creation/deletion unit receives the FRT reception result(S804), and identifies the FRT processing result. If the FRT receptionresult indicates an error (No in S805), the process is terminated as anerror. If the FRT reception result indicates a success (Yes in S805), asession clear command is sent and received (S806, S819). Then, theauthentication table created in the device is discarded (S820), and theprocess is completed. The authentication table is created for the mutualauthentication processing in steps S801 and S810, and has theconfiguration shown in FIG. 51 discussed in the section of theprocessing using the partition registration ticket (PRT).

[1074] As discussed above, by using the file registration ticket (FRT),a file is created in the partition set in the device or the created fileis deleted from the partition in the device. The file creation anddeletion processing (S815) included in the processing shown in FIG. 72is described in detail below with reference to FIG. 73.

[1075] (File Creation/Deletion Processing)

[1076] Details of the partition creation/deletion processing based onthe file registration ticket (FRT) performed in step S815 of the flow inFIG. 72 are described by using the processing flow of FIG. 73. The filecreation/deletion processing is the processing performed by the device,which has received the file registration ticket (FRT) from the ticketuser (ex. a reader/writer or a PC as the device access unit), based onthe file registration ticket (FRT).

[1077] In step S821 of FIG. 73, the device checks the processing typerecorded in the received file registration ticket (FRT), i.e., theoperation type (indicating whether the partition is to be generated ordeleted). If the operation type is file creation, step S822 and thesubsequent steps are executed, and if the operation type is filedeletion, step S841 and the subsequent steps are executed.

[1078] The file creation processing is as follows. In step S822, thedevice determines whether there is a file having the same ID as the fileidentifier (ID) indicated in the file registration ticket (FRT) in thepartition to be processed by the device. This determination can be madeby checking whether the same file ID as the file ID indicated in thereceived ticket (FRT) is recorded in the file definition block (see FIG.24) of the partition area set in the device memory.

[1079] If there is a file having the same code (PMC) in the device, thefile creation cannot be performed since the duplication of files havingthe same code in the same partition is not permitted, and the processingis terminated as an error. If there is no file having the same code inthe partition to be processed, in step S823, the free block number inpartition in the partition management information block (see FIG. 20) iscompared with the file size indicated in the file registration ticket(FRT), and it is determined whether there is a free block area which isgreater than or equal to the file size indicated in the ticket (FRT) inthe partition to be processed by the device. If there is no free blockarea which is greater than or equal to the partition size, a file havingthe size indicated in the FRT cannot be created, and thus, the processis terminated as an error.

[1080] If it is determined that there is a free block area which isgreater than or equal to the file size indicated in the ticket (FRT) inthe corresponding partition of the device memory, the process proceedsto step S824. In step S824, the pointer of free area in the partitionmanagement information block is checked, and the file definition block(FDB) area (see FIG. 24) is reserved in the uppermost block of the freearea in partition.

[1081] Then, the device copies the file ID indicated in the fileregistration ticket (FRT) into the reserved file definition block (FDB)area (S825), and also copies the pointer of free area of the partitionmanagement information block (see FIG. 20) into the file start positionof the file definition block (FDB) area (S826).

[1082] In step S827, the device also copies the corresponding dataindicated in the file registration ticket (FRT) into the file size, theservice permission ticket issuing means code (SPTIC) and version thereof(SPTIC Version), the file structure type code, and the acceptableauthentication type and the acceptable verification type used forperforming file access of the file definition block (PDB).

[1083] Then, in step S828, Kspt_Encrypted (data Kfrt(Kspt) obtained byencrypting the MAC checking key Kspt of the service permission ticket(SPT) indicated in the file definition block with the MAC checking keyKfrt of the file registration ticket of the corresponding partition)stored in the file registration ticket (FRT) is decrypted by using theMAC checking key Kfrt of the file registration ticket, and is stored inthe file definition block (FDB). The MAC checking key Kfrt of the fileregistration ticket has been stored in the partition key area when thepartition is created.

[1084] Then, in step S829, the device subtracts the file size +1 fromthe free block number in partition in the partition managementinformation block (see FIG. 20), where +1 means a block for the filedefinition block (FDB).

[1085] Subsequently, in step S830, the device adds the file size to thepointer of free area in the partition management information block (seeFIG. 20), and in step S831, the device adds 1, i.e., the number ofcreated file (1), to the file number of the partition managementinformation block.

[1086] Then, in step S832, the device performs initial processingaccording to the file structure (the file to be created) stored in thefile registration ticket (FRT). For example, if the file structure israndom, resetting to 0 is performed, and if the file structure iscyclic, the pointer and the data are set to 0. According to thisprocessing, a new file is created in the generated partition.

[1087] The file deletion processing in steps S841 through S848 of FIG.73 is described below. In step S841, it is determined whether there is afile having the same ID as the file ID indicated in the fileregistration ticket (FRT) in the corresponding partition of the devicememory. This determination can be made by checking whether the same fileID as the file ID of the received ticket (FRT) is indicated in the filedefinition block (see FIG. 24) of the device memory.

[1088] If there is no file having the same file ID in the correspondingpartition, the file cannot be deleted, and the process is terminated asan error. If there is a file having the same ID in the correspondingpartition, it is determined in step S842 whether there is a file whichhas been created after the file to be deleted. If there is no file whichhas been created after the file to be deleted, the file to be deleted isthe latest file, and the file definition block (FDB) (see FIG. 24) ofthe target file is deleted in step S849.

[1089] If it is determined in step S842 that there is a file which hasbeen created after the file to be deleted in the correspondingpartition, the data of the later file is displaced to the lower side bythe size of the file (FS) to be deleted (S843), and the file definitionblock (FDB) of the later file is displaced to the upper side by oneblock (S844). Moreover, the size of the file to be deleted (FS) issubtracted from the file start position recorded in the file definitionblock (FDB) of the later file (S845).

[1090] After the processing of step S845 or S849, in step S846, the sizeof the file to be deleted (FS) +1 is added to the free block number inpartition of the partition management information block (PMIB) (see FIG.20), where +1 means a block for the file definition block of the file tobe deleted.

[1091] Subsequently, in step S847, the size of the file to be deleted(FS) is subtracted from the value of the pointer of free area in thepartition management information block (PMIB) (see FIG. 20). In stepS848, 1, i.e., the number of deleted file (1), is subtracted from thefile number of the partition management information block (PMIB) (seeFIG. 20), and then, the file deletion processing based on the fileregistration ticket (FRT) is completed.

[1092] The foregoing processing is the file creation/deletion processingbased on the file registration ticket (FRT) in step S815 of theprocessing flow of FIG. 72.

[1093] An example of the data configuration stored in the device memorywhen the file creation processing by the partition manager is finishedis shown in FIG. 74. In the partition area shown in FIG. 74, the data inthe following block and area are written during the file creation or thepartition creation:

[1094] file definition block (1−N);

[1095] partition key area;

[1096] common-key partition key information block (partition keydefinition block(Common));

[1097] public-key partition key information block (partition keydefinition block(PUB)); and

[1098] partition management information block. The file area (file dataarea 1−N) is reserved in the corresponding partition by the filecreation processing.

[1099] [B4.5. Processing Procedure in Each File Creation ProcessingMethod]

[1100] In the above-described file setting registration processing,mutual authentication is conducted between the device and thereader/writer as the device access unit, which serves as a fileregistration ticket user, managed by the partition manager, and a fileis set based on the file registration ticket (FRT). There are two typesof mutual authentication modes, i.e., the public-key mutualauthentication and the common-key mutual authentication. There are alsotwo types of ticket (FRT) verification processing modes, i.e., thepublic-key signature verification and the common-key MAC checking. Thatis, the following four processing modes are primarily provided:

[1101] (A) mutual authentication (public key) and ticket (FRT)verification (public key);

[1102] (B) mutual authentication (public key) and ticket (FRT)verification (common key);

[1103] (C) mutual authentication (common key) and ticket (FRT)verification (common key); and

[1104] (D) mutual authentication (common key) and ticket (FRT)verification (public key).

[1105] The four processing modes are briefly discussed with reference tothe drawings by emphasizing the data transfer processing executed amongthe entities, such as the certificate authority (CA(PM)), the partitionmanager (PM), and the device.

[1106] (A) Mutual Authentication (Public Key) and Ticket (FRT)Verification (Public Key)

[1107] A description is first given, with reference to FIG. 75, of thedata transfer performed among the entities when the public key system isused for mutual authentication processing and the public key system isused for ticket (FRT) verification.

[1108] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 75. The processing is described belowaccording to the numbers.

[1109] (1) Issuing of Public Key Certificate (Cert. FRT Issuer) of FileRegistration Ticket Issuing Means (FRT Issuer)

[1110] In response to a request from the file registration ticketissuing means (FRT Issuer), the public key certificate (Cert. FRTIssuer) of the file registration ticket issuing means (FRT Issuer) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Thepartition manager may serve as the file registration ticket issuingmeans (FRT Issuer), in which case, the public key certificate of thepartition manager (PM) can be used as the public key certificate of thefile registration ticket issuing means (FRT User).

[1111] (2) Issuing of Public Key Certificate (Cert. FRT User) of FileRegistration Ticket User (FRT User)

[1112] In response to a request from the file registration ticket user(FRT User: and more specifically, a reader/writer as the device accessunit that sends a ticket to the device), the public key certificate(Cert. FRT User) of the file registration ticket user (FRT User) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Thepartition manager may serve as the file registration ticket user (FRTUser), in which case, the public key certificate of the partitionmanager (PM) can be used as the public key certificate of the fileregistration ticket user (FRT User).

[1113] (3) Creation Processing of File Registration Ticket (FRT)

[1114] The file registration ticket (FRT) is created by the fileregistration ticket (FRT) issuing means (FRT Ticket Issuer) managed bythe partition manager. In this case, for creating and verifying thepublic-key signature, the signature is created by the private key of thefile registration ticket issuing means (FRT Ticket Issuer) (see FIG.12), and is added to the FRT.

[1115] (4) Supply of FRT and Public Key Certificate (Cert. FRT Issuer)of File Registration Ticket Issuing Means (FRT Ticket Issuer) to FileRegistration Ticket User (FRT User)

[1116] The file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager is supplied to the file registration ticket user (FRTUser), i.e., the unit (ex. a reader/writer as the device access unit)that sends the ticket to the device, together with the public keycertificate (Cert. FRT Issuer) of the file registration ticket issuingmeans (FRT Ticket Issuer).

[1117] (5) Mutual Authentication Between File Registration TicketIssuing Means and Device

[1118] The partition manager (and more specifically, a reader/writer asthe device access unit, which serves as the file registration ticketuser (FRT User)) sends the public key certificate (Cert. FRT User) ofthe ticket user (FRT User) to the device, which is to generate a fileaccording to the file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer), therebyperforming public-key mutual authentication (see FIG. 50).

[1119] (6) Supply of FRT and Public Key Certificate (Cert. FRT Issuer)of File Registration Ticket Issuing Means (FRT Ticket Issuer) to Device

[1120] After the mutual authentication has been successfully conductedbetween the partition manager (PM) and the device, the partition manager(PM) (and more specifically, a reader/writer as the device access unit,which serves as the file registration ticket user (FRT User)) sends thefile registration ticket (FRT) and the public key certificate (Cert. FRTIssuer) of the file registration ticket issuing means (FRT TicketIssuer) to the device.

[1121] The device has checked the following factors concerning thereceived file registration ticket (FRT): (1) the public key certificate(CERT FRT Issuer) of the ticket issuer is an authorized public keycertificate (CERT) without being tampered with; (2) the code recorded inthe option area of the public key certificate (CERT FRT Issuer) of theticket issuer coincides with the ticket issuing means code (FRTIC: FRTIssuer Category) recorded in the device PKDB (Partition Key DefinitionBlock)(PUB); (3) the ticket issuing means (Ticket Issuer) is notrevoked; and (4) the ticket has not been tampered with by verifying thesignature of the received ticket (FRT). The FRT user (a reader/writer asthe device access unit) is also verified (see FIGS. 57 and 58) byverifying whether mutual authentication has been conducted by checkingwhether the identifier, the category, or the serial (SN) name of the FRTuser (a reader/writer as the device access unit, which serves as theticket user) stored in the FRT ticket coincides with the identifier, thecategory, or the serial (SN) name recorded as the ID data (DN) of thepublic key certificate (Cert. FRT User) of the ticket user (FRT User).

[1122] (7) Registration of SPTIC and Kspt in FDB

[1123] The device registers the service permission ticket (STP) user(SPTIC) (ex. a reader/writer as the device access unit that accesses thedata in the device file) and Kspt (the MAC checking key (Kspt) of theservice permission ticket (SPT)) in the file definition block (FDB) (seesteps S827 and S828 of the flow in FIG. 73).

[1124] (8) Reservation of File Data Area

[1125] The device reserves a file area having the size indicated in thefile registration ticket (FRT) in the corresponding partition.

[1126] By performing the above-described processing, the file creationprocessing in accordance with the mutual authentication (public key) andticket (FRT) verification (public key) can be executed.

[1127] (B) Mutual Authentication (Public Key) and Ticket (FRT)Verification (Common Key)

[1128] The data transfer performed among the entities when the publickey system is applied to the mutual authentication processing and thecommon key system is applied to the ticket (FRT) verification isdescribed below with reference to FIG. 76.

[1129] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 76. The processing is discussed belowaccording to the numbers.

[1130] (1) Issuing of Public Key Certificate (Cert. FRT User) of FileRegistration Ticket User (FRT User)

[1131] In response to a request from the file registration ticket user(FRT User: and more specifically, a reader/writer as the device accessunit that sends the ticket to the device), the public key certificate(Cert. FRT User) of the file registration ticket user (FRT User) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Thepartition manager may serve as the file registration ticket user (FRTUser), in which case, the public key certificate of the partitionmanager (PM) can be used as the public key certificate of the fileregistration ticket user (FRT User).

[1132] (2) Creation Processing of File Registration Ticket (FRT)

[1133] The file registration ticket (FRT) is created by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager. In this case, the MAC (Message Authentication Code)(see FIG. 59) is added to the FRT as the common-key verification value.

[1134] (3) Supply of FRT to File Registration Ticket User (FRT User)

[1135] The file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager is supplied to the file registration ticket user (FRTUser), namely, to the unit (ex. a reader/writer as the device accessunit) that sends the ticket to the device.

[1136] (4) Mutual Authentication Between File Registration TicketIssuing Means and Device

[1137] The partition manager (and more specifically, a reader/writer asthe device access unit, which serves as the file registration ticketuser (FRT User)) sends the public key certificate (Cert. FRT User) ofthe ticket user (FRT User) to the device, which is to generate a fileaccording to the file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer), therebyperforming public-key mutual authentication (see FIG. 50).

[1138] (5) Supply of FRT to Device

[1139] After the mutual authentication between the partition manager(PM) and the device has been successfully conducted, the partitionmanager (PM) (and more specifically, a reader/writer as the deviceaccess unit, which serves as the file registration ticket user (FRTUser)) sends the file registration ticket (FRT) to the device. Thedevice performs MAC verification for the received file registrationticket (FRT), and verifies the FRT issuer. The device also verifies theFRT user (PM: a reader/writer as the device access unit) (see FIGS. 57and 58) by determining whether mutual authentication has been conductedby checking whether the identifier, the category, or the serial (SN)name of the FRT user (a reader/writer as the device access unit, whichserves as the ticket user) stored in the FRT ticket coincides with theidentifier, the category, or the serial (SN) name recorded as the IDdata (DN) of the public key certificate of the partition manager.

[1140] (6) Registration of SPTIC and Kspt in FDB

[1141] The device registers the service permission ticket (STP) issuercategory (SPTIC) (ex. a reader/writer as the device access unit thataccesses the data in the device file) and Kspt (the MAC checking key(Kspt) of the service permission ticket (SPT)) in the file definitionblock (FDB) (see steps S827 and S828 of the flow in FIG. 73).

[1142] (8) Reservation of File Data Area

[1143] The device reserves a file area having the size indicated in thefile registration ticket (FRT) in the corresponding partition.

[1144] By performing the above-described processing, the file creationprocessing according to the mutual authentication (public key) andticket (FRT) verification (common key) can be executed.

[1145] (C) Mutual authentication (Common Key) and Ticket (FRT)Verification (Common Key)

[1146] The data transfer performed among the entities when the commonkey system is applied to the mutual authentication processing and thecommon key system is applied to ticket (FRT) verification is describedbelow with reference to FIG. 77.

[1147] The data transfer is performed among the entities in the order ofthe numbers indicated in FIG. 77. The processing is described accordingto the numbers.

[1148] (1) Issuing Processing of File Registration Ticket (FRT)

[1149] The file registration ticket (FRT) is issued by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager. In this case, the MAC (Message Authentication Code)(see FIG. 59) is added to the FRT as the common-key verification value.

[1150] (2) Supply of FRT to File Registration Ticket User (FRT User)

[1151] The file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager is sent to the file registration ticket user (FRTUser), namely, to the unit (ex. a reader/writer as the device accessunit) that sends the ticket to the device.

[1152] (3) Mutual Authentication Between File Registration TicketIssuing Means and Device

[1153] The partition manager (and more specifically, a reader/writer asthe device access unit, which serves as the file registration ticketuser (FRT User)), performs the common-key mutual authentication (seeFIGS. 53 and 54) with the device, which is to generate a file accordingto the file registration ticket (FRT) issued by the file registrationticket issuing means (FRT Ticket Issuer).

[1154] (4) Supply of FRT to Device

[1155] After the mutual authentication between the partition manager(PM) and the device has been successfully conducted, the partitionmanager (PM) (and more specifically, a reader/writer as the deviceaccess unit, which serves as the file registration ticket user (FRTUser)) sends the file registration ticket (FRT) to the device. Thedevice performs MAC verification for the received file registrationticket (FRT), and verifies the FRT issuer. The device also verifies theFRT user (PM: a reader/writer as the device access unit) (see FIGS. 57and 58) by determining whether mutual authentication has been conductedby checking whether the identifier of the FRT user (a reader/writer asthe device access unit, which serves as a ticket user) stored in the FRTticket coincides with the received identifier of the partition manager.

[1156] (6) Registration of SPTIC and Kspt in FDB

[1157] The device registers the service permission ticket (STP) issuercategory (SPTIC) (ex. a reader/writer as the device access unit thataccesses the data in the device file) and Kspt (the MAC checking key(Kspt) of the service permission ticket (SPT)) in the file definitionblock (FDB) (see steps S827 and S828 of the flow in FIG. 73).

[1158] (8) Reservation of File Data Area

[1159] The device reserves a file area having the size indicated in thefile registration ticket (FRT) in the corresponding partition.

[1160] By performing the above-described processing, the file creationprocessing according to the mutual authentication (common key) andticket (FRT) verification (common key) is executed.

[1161] (D) Mutual Authentication (Common Key) and Ticket (FRT)Verification (Public Key)

[1162] The data transfer performed among the entities when the commonkey system is applied to the mutual authentication processing and thepublic key system is applied to the ticket (FRT) verification isdescribed below with reference to FIG. 78.

[1163] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 78. The processing is described belowaccording to the numbers.

[1164] (1) Issuing of Public Key Certificate (Cert. FRT Issuer) of FileRegistration Ticket Issuing Means (FRT Issuer)

[1165] In response to a request from the file registration ticketissuing means (FRT Issuer), the public key certificate (Cert. FRTIssuer) of the file registration ticket issuing means (FRT Issuer) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Thepartition manager may serve as the file registration ticket issuingmeans (FRT Issuer), in which case, the public key certificate of thepartition manager (PM) can be used as the public key certificate of thefile registration ticket issuing means (FRT User).

[1166] (2) Creation Processing of File Registration Ticket (FRT)

[1167] The file registration ticket (FRT) is created by the fileregistration ticket (FRT) issuing means (FRT Ticket Issuer) managed bythe partition manager. In this case, for creating and verifying thepublic-key signature, the signature is created by the private key of thefile registration ticket issuing means (FRT Ticket Issuer) (see FIG.12), and is added to the FRT.

[1168] (3) Supply of FRT and Public Key Certificate (Cert. FRT Issuer)issued by File Registration Ticket Issuing Means (FRT Ticket Issuer) toFile Registration Ticket User (FRT User)

[1169] The file registration ticket (FRT) issued by the fileregistration ticket issuing means (FRT Ticket Issuer) managed by thepartition manager is sent to the file registration ticket user (FRTUser), i.e., to the unit (ex. a reader/writer as the device access unit)that sends the ticket to the device, together with the public keycertificate (Cert. FRT Issuer) of the file registration ticket issuingmeans (FRT Ticket Issuer).

[1170] (4) Mutual Authentication Between File Registration TicketIssuing Means and Device

[1171] The partition manager (and more specifically, a reader/writer asthe device access unit, which serves as the file registration ticketuser (FRT User)) performs the common-key mutual authentication (seeFIGS. 53 and 54) with the device, which is to generate a file accordingto the file registration ticket (FRT) issued by the file registrationticket issuing means (FRT Ticket Issuer).

[1172] (5) Supply of PRT and Public Key Certificate (Cert. FRT Issuer)of File Registration Ticket Issuing Means (FRT Ticket Issuer) to Device

[1173] After the mutual authentication has been successfully conductedbetween the partition manager (PM) and the device, the partition manager(PM) (and more specifically, a reader/writer as the device access unit,which serves as the file registration ticket user (FRT User)) sends thefile registration ticket (FRT) and the public key certificate (Cert. FRTIssuer) of the file registration ticket issuing means (FRT TicketIssuer) to the device.

[1174] The device has checked the following factors concerning thereceived file registration ticket (FRT): (1) the public key certificate(CERT FRT Issuer) of the ticket issuer is an authorized public keycertificate (CERT) without being tampered with; (2) the code recorded inthe option area of the public key certificate (CERT FRT Issuer) of theticket issuer coincides with the ticket issuing means code (FRTIC: FRTIssuer Category) recorded in the device PKDB (Partition Key DefinitionBlock)(PUB); (3) the ticket issuing means (Ticket Issuer) is notrevoked; and (4) the ticket has not been tampered with by verifying thesignature of the received ticket (FRT). The FRT user (a reader/writer asthe device access unit) is also verified (see FIGS. 57 and 58) bydetermining whether mutual authentication has been conducted by checkingwhether the identifier of the FRT user (a reader/writer as the deviceaccess unit, which serves as a ticket user) stored in the FRT ticketcoincides with the identifier of the ticket user (FRT User).

[1175] (6) Registration of SPTIC and Kspt in FDB

[1176] The device registers the service permission ticket (STP) issuercategory (SPTIC) (ex. a reader/writer as the device access unit thataccesses the data in the device file) and Kspt (the MAC checking key(Kspt) of the service permission ticket (SPT)) in the file definitionblock (FDB) (see steps S827 and S828 of the flow in FIG. 73).

[1177] (7) Reservation of File Data Area

[1178] The device reserves a file area having the size indicated in thefile registration ticket (FRT) in the corresponding partition.

[1179] By performing the above-described processing, the file creationprocessing according to the mutual authentication (common key) andticket (FRT) verification (public key) can be executed.

[1180] [B4.6. Service (File Access) Processing Using Service PermissionTicket (SPT)]

[1181] The file access processing using the service permission ticket(SPT) (see FIGS. 28 and 31) is described below with reference to theflow of FIG. 79 and the other drawings. The file access processingincludes mutual authentication processing (device authentication orpartition authentication) between the device and the file access unit,and the integrity verification processing of the service permissionticket (SPT).

[1182] In the flow of FIG. 79, the processing of the file access unit isshown at the left side, and the processing of the device (see FIG. 5) isshown at the right side. The file access unit is the management unit ofthe partition manager, and is the unit (ex. a reader/writer or a PC asthe device access unit) which is able to read and write data from andinto the device, and corresponds to the reader/writer as the deviceaccess unit shown in FIG. 10. An overview of the file access processingperformed by the file access unit is described below with reference toFIG. 79, and then, details of the individual processings included in thefile access processing are sequentially discussed with reference to theflow of FIG. 80 and the subsequent drawings.

[1183] In steps S851 and S860, mutual authentication processing is firstperformed between the file access unit and the device. Between the twomeans for performing data sending and receiving, it is first checkedwith each other whether they are authorized data communication means,and then, data transfer is performed according to the necessity. Themutual authentication processing is to check whether the other party isauthorized data communication means. In the mutual authenticationprocessing, a session key is created, and data is encrypted by using thesession key as the common key. Then, the data is transferred.

[1184] In the mutual authentication processing, partition authenticationis performed, as has been discussed in the section of the partitioncreation/deletion processing. Either the common-key authentication orthe public-key authentication is used for the mutual authenticationprocessing. This mutual authentication processing is similar to thatdescribed with reference to FIGS. 48 through 56, and an explanationthereof is thus omitted.

[1185] The processing to be executed as the mutual authenticationprocessing is determined by:

[1186] Authentication Flag: the flag indicating whether mutualauthentication with the device is required for using the ticket; and

[1187] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device; of the service permission ticket (SPT) (see FIGS. 28 and 31)to be used.

[1188] If authentication processing has failed (No in step S852 orS861), it means that it cannot be verified that the two means areauthorized device and unit. Accordingly, the subsequent processing isnot executed, and the process is terminated as an error.

[1189] The device is also able to perform processing so that access tofiles in a plurality of different partitions can be made based on aplurality of service permission tickets (SPTs). For example, access canbe made to files in a plurality of different partitions based on aplurality of service permission tickets (SPTs) on condition that deviceauthentication has been successfully conducted. The file access rules ineach partition are indicated in the service permission ticket (SPT) tobe configured as the access control data. The device receives aplurality of service permission tickets (SPTs) from the access unit, andif each ticket indicates that device authentication is required, fileaccess in each partition is allowed on condition that deviceauthentication has been successfully conducted according to the rules.

[1190] If the authentication conditions are different among theplurality of service permission tickets (SPTs), access can be made todesignated files in the plurality of service permission tickets (SPTs)on condition that partition authentication set in each servicepermission ticket (SPT) has been successfully conducted.

[1191] Subsequently, in step S853, the file access unit sends theservice permission ticket (SPT) to the device. The service permissionticket (SPT) is the ticket issued by the service permission ticket (SPT)issuing means (SPT Issuer) managed by the partition manager. The servicepermission ticket (SPT) is the access control ticket for the device, andhas the format configuration shown in FIGS. 28 and 31.

[1192] When sending the service permission ticket (SPT) to the ticketuser, the public key certificate (CERT_SPTI) of the service permissionticket (SPT) issuing means (SPT Issuer) is sent together if the publickey system is employed. The attribute of the public key certificate(CERT_SPTI) of the SPT issuing means coincides with the ticket issuingmeans code (SPTIC) recorded in FDB (File Definition Block) in thedevice.

[1193] Upon receiving the file registration ticket (SPT) (S862), thedevice checks the integrity of the received ticket (SPT) and the user(S863). The integrity checking of the ticket is performed by using theMAC checking of the common key system or the signature verification ofthe public key system. The user checking is to check the integrity ofthe unit (ticket user) that has sent the ticket. The user checking isperformed by determining whether mutual authentication has beenconducted by checking the consistency of the ID data of the unit to beauthenticated and the ticket user identifier (see FIGS. 28 and 31)recorded in the ticket. These processings are similar to those discussedwith reference to FIGS. 57 through 59, as has been discussed in thesection of the partition registration ticket (PRT), and an explanationthereof is thus omitted.

[1194] After the verification processing of the received ticket (SPT)and the user, if it cannot be determined that the ticket and the userare authorized ticket and user (No in step S864), the device sends aservice permission ticket (SPT) reception error to the file access unit(S868). If it can be determined that the ticket and the user areauthorized ticket and user (Yes in S864), the file stored in the devicememory is opened according to the rules indicated in the receivedservice permission ticket (SPT). Details of the file open processing aredescribed below by using a different flow.

[1195] If the file open processing has succeeded according to thedescription recorded in the service permission ticket (SPT) (Yes inS866), an SPT reception success is informed to the file access unit(S867). If the file open processing has failed (No in S866), an SPTreception error is informed to the file access unit (S868).

[1196] The file access unit receives the SPT reception result (S854),and determines the SPT processing result. If the SPT reception resultindicates an error (No in S855), the file access unit terminates theprocess as an error. If the SPT reception result indicates a success(Yes in S855), the file access unit determines whether all the SPTs havebeen sent (S856). If there is an SPT to be sent, step S853 and thesubsequent steps are repeated.

[1197] If all the SPTs have been sent, the file access is performedaccording to the service permission ticket (SPT) in steps S857 and S869.Upon completion of the file access processing, a session clear commandis sent and received (S858 and S870), and the authentication tablecreated in the device is discarded (S871). The process is thencompleted. Details of the file access processing are described below byusing a different flow. The authentication table is the table created inthe mutual authentication processing in steps S851 and S860, and has theconfiguration similar to that shown in FIG. 51, as has been discussed inthe section of the partition registration ticket (PRT).

[1198] As described above, access can be made to a file in a partitionset in the device by using the service permission ticket (SPT). The fileopen processing (S865) and various file access processing (S857 andS869) included in the file access processing are described below.

[1199] (File Open Processing)

[1200] The file open processing (S865 in FIG. 79) is described belowwith reference to the flow of FIG. 80. The file open processing is theprocessing executed by the device according to the received servicepermission ticket (SPT).

[1201] In step S881, the device determines whether the file specified inthe received service permission ticket (SPT) has been created and ispresent in the device. The file ID (see FIGS. 28 and 31) of the file tobe processed is recorded in the service permission ticket (SPT), and thefile definition block (FIG. 24), for example, is checked for thepresence of a file having the same ID as the ID recorded in the servicepermission ticket (SPT). If there is no file having the same ID as theID indicated in the ticket, the processing cannot be performed, and theprocess is terminated as an error.

[1202] If there is a file having the same ID as the ID indicated in theticket, in step S882, an entry in which the ticket issuing means (Ticketissuer=PMC: Partition manager Code) indicated in the service permissionticket (SPT) and the file ID indicated in the service permission ticket(SPT) are related to each other is written into the file open table.

[1203] In step S883, the file access mode [File Access Mode: the mode ofaccess to the file] indicated in the service permission ticket (SPT) iswritten in correspondence with the entry created in the file open table.In step S884, the group file [Group of Target File: the group of filesto be accessed] indicated in the service permission ticket (SPT) iswritten. In step S885, the access file identifier [Target File ID: theidentifier (ID) of the file to be accessed] indicated in the servicepermission ticket (SPT) is written. In step S886, the processing mode tothe target file [Read/Write Permission: the processing mode of thetarget file to be accessed (read or write permission)] indicated in theservice permission ticket (SPT) is written. The processing to beperformed on the target file includes read, write, and other types ofprocessings.

[1204] Examples of the configuration of the file open table are shown inFIGS. 81 and 82. The file open table is the table in which informationindicating files that are being accessed in the device and access modesthereof, and other types of information are recorded. The informationindicated in the service permission ticket (SPT) received by the deviceis recorded in the file open table, and the file open table is thenstored in the storage means of the device.

[1205] If the service permission ticket is the type which permits accessonly to a single file (see FIG. 28), the file open table includes thefollowing items of information:

[1206] Ticket Issuer: the identifier of the ticket issuing means (TicketIssuer);

[1207] File ID: the identifier (ID) of the access file in the partition;and

[1208] File Access Mode: the access mode to the file. An example of theconfiguration of the file open table when the service permission ticket(SPT) is the above-described type is shown in FIG. 81.

[1209] As shown in FIG. 81, in the file open table, the partitionmanager code (PMC) is indicated as the identifier of the ticket issuingmeans (Ticket Issuer), which is group information, so that the partitioncan be identified. The file can be identified by the file ID. The accessmode to be executed (ex. read, write, or encryption/decryption (Enc,Dec)) can be identified by the file access mode.

[1210] If the service permission ticket (SPT) is the type which permitsaccess to a plurality of files among the files set in the partitions(see FIG. 31), the following items of information in addition to theabove-described items of information are written into the file opentable:

[1211] Group of Target File: the group of files to be accessed;

[1212] Target File ID: the ID of the file to be accessed; and

[1213] Read/Write Permission: the processing mode (read or write) to thefile to be accessed (target file). An example of the configuration ofthe file open table is shown in FIG. 82.

[1214] As shown in FIG. 82, in the file open table which is set for theservice permission ticket of the type in which access can be made to aplurality of files, in addition to the data shown in FIG. 81, thepartition manager code (PMC) as the partition ID data of the group oftarget files to be accessed, the file ID as the identifier (ID) of thetarget file to be accessed, and [Read/Write Permission] data indicatingthe processing mode of the target file are stored. Accordingly, it ispossible to identify the types of processings to be executed on aplurality of files.

[1215] The processing mode in which access is made to a plurality offiles is performed when, for example, data stored in file B is encryptedby using a key stored in file A. To perform this processing, it isnecessary that file B should give a permission in response to a readdemand of file A. In this case, file B is referred to as a “sourcefile”, while the file to which file B gives a permission is referred toas a “target file”.

[1216] As described above, based on the service permission ticket (SPT)received during the session with the access unit, the device creates afile open table in which the partition manager code (PMC) as the ticketissuing means (Ticket Issuer (PMC)), the file identifier as the ID dataof the file on which the file open processing is performed, and theaccess mode indicated in the service permission ticket (SPT) are relatedto each other. Accordingly, the device is able to determine by referringto the file open table whether a command received from the access unitcan be executed.

[1217] (File Access Processing)

[1218] Details of the file access processing performed in step S857 orS869 in FIG. 79 are described below.

[1219] The access processing to be executed when the file open tableshown in FIG. 81 is created is discussed with reference to FIG. 83. Twofile access units (R/W: reader writers as the device access units) 750and 760 are shown at the left side, and a partition containing files ofthe device 100 is shown at the right side.

[1220] It is now assumed that, after conducting mutual authenticationwith the device, the file access unit (R/W: reader/writer) 750 has sentan access permission ticket having the file ID: [0x0002] and the fileaccess mode: [Read] to the device 100, and has succeeded in theverification of the ticket, the ticket issuer, and the user.

[1221] In this case, the entry of the second row of the file open tableshown in FIG. 81 is generated in the device. This entry indicates thatthe access mode [Read] processing can be performed on the file ID[0x0002] in the partition identified by the partition manager code(PMC).

[1222] In this case, the file access unit (R/W: reader/writer) 750generates a command and sends it to the device. For example, uponreceiving a data read command for the file ID [0x0002]: Read Command(0x0002), the device checks the entry of the file open table, andidentifies that the access mode [Read] can be executed for the file ID[0x0002], and then, performs reading processing.

[1223] If the file access unit (RIW: reader/writer) 750 sends, forexample, a data write command for the file ID [0x0002]: Write Command(0x0002), or a data encryption processing command for the file ID[0x0001]: Encryption Command (0x0001), to the device, the devicereceives the command, checks the entry of the file open table, andidentifies that [Write] processing for the file ID [0x0002] or[Encryption processing] for the file ID [0x0001] is not permitted by theservice permission ticket (SPT) received from the file access unit (R/W:reader/writer) 750. Thus, the device terminates the process.

[1224] It is now assumed that, after conducting mutual authenticationwith the device, the file access unit (R/W: reader/writer) 760 sends anaccess permission ticket having the file ID: [0x0001] and the fileaccess mode: [encryption/decryption processing: Enc&Dec] to the device100, and has succeeded in the verification of the ticket, the ticketissuer, and the user.

[1225] In this case, the entry of the first row of the file open tableshown in FIG. 81 is generated in the device. This entry indicates thatthe access mode [encryption/decryption processing: Enc&Dec] can beexecuted for the file ID [0x0001] in the partition identified by thepartition manager code (PMC1).

[1226] In this case, the file access unit (R/W: reader/writer) 760generates a command and sends it to the device. For example, uponreceiving the encryption command for the file ID [0x0001] [EncryptionCommand (0x0001)], the device checks the entry of the file open table,identifies that the access mode [encryption/decryption processing:Enc&Dec] can be executed for the file ID: 0x0001, and executes theencryption processing.

[1227] If the file access unit (R/W: reader/writer) 760 sends, forexample, a data read command for the file ID [0x0002]: Read Command(0x0002) to the device, the device receives the command, checks theentry of the file open table, and identifies that the [Read] processingfor the file ID [0x0002] is not permitted by the service permissionticket (SPT) received from the file access unit (R/W: reader/writer)760. Thus, the device terminates the process.

[1228] As discussed above, based on the service permission ticket (SPT)received by the device from the reader/writer as the device access unit,which serves as the service permission ticket user, the device creates afile open table according to the processing flow of FIG. 80, determineswhether each command from the reader/writer as the file access unit canbe executed based on the generated file open table, and executes thedetermined processing.

[1229] Then, the access processing to be performed on two files isdiscussed below with reference to FIG. 84. In FIG. 84, two file accessunits (R/Ws: reader/writers) 770 and 780 are shown at the left side, anda partition containing files of the device 100 is shown at the rightside.

[1230] An example of the processing using the service permission ticket(SPT) (see FIG. 31) that designates the target file is first discussed.

[1231] It is now assumed that, after conducting mutual authenticationwith the device, the file access unit (R/W: reader/writer) 770 sends twoaccess permission tickets, i.e., an access permission ticket having SPTformat 1 (file ID: [0x0001], and file access mode:[encryption/decryption processing: Enc&Dec]), and an access permissionticket having SPT format 2 (file ID [0x0002], target file group: [PMC1],target file ID: [0x0001], and read/write permission: [Read]), to thedevice 100, and that the file access unit 770 has succeeded in theverification of the ticket, the ticket issuer, and the user.

[1232] In this case, the entries of the file open table shown in FIG. 82are generated in the device. These entries indicate that the file ID[0x0001] in the partition identified by the partition manager code(PMC1) is a key file, and is opened so that encryption and decryptioncan be performed, and that the file ID [0x0002] is a data file, andcannot be externally read since the column of the file access mode isblank, and thus, the file ID [0x0002] is opened so that it can be readfor the file ID [0x0001] and is set as the entry of the file open table.

[1233] In this case, the file access unit (R/W: reader/writer) 770generates a command and sends it to the device. For example, the fileaccess unit sends a command for reading the file ID [0x0002] and forperforming an internal encryption for the file ID [0x0001]: InternalEncryption Command (0x0001, 0x0002). Upon receiving the command, thedevice checks the entries of the file open table, and identifies that[Read] can be performed for the file ID [0x0002] so that [Encryptionprocessing] can be executed for the target file [0x0001] of the targetfile group [PMC1]. The device then reads the data of the file ID[0x0002], and performs encryption by using the key of the file ID[0x0001], and sends the encrypted data to the access unit.

[1234] According to the processing using the service permission ticket(SPT) (see FIG. 31) that designates the target file, data read from afile can be encrypted by using an encryption key stored in another fileso as to obtain the encrypted data. Thus, a leakage of the decrypteddata to an external source can be prevented.

[1235] A description is now given of the processing when a plurality ofservice permission tickets (SPTs) (see FIG. 28) that each specify theprocessing to be executed on a single file are used rather than theservice permission ticket (SPT) (see FIG. 31) that specifies targetfile.

[1236] It is now assumed that, after conducting mutual authenticationwith the device, the file access unit (R/W: reader/writer) 780 sends twoaccess tickets, i.e., an access ticket having SPT format 1 (file ID:[0x0002] and a file access mode: [Read], and an access ticket having SPTformat 2 (file ID: [0x0001] and file access mode [encryption/decryptionprocessing: Enc&Dec]) to the device 100, and has succeeded in theverification of the ticket, the ticket issuer, and the user.

[1237] In this case, the entries of the first and second rows of thefile open table shown in FIG. 81 are generated in the device. Theseentries indicate that the access mode [Encryption/decryption processing:Enc&Dec] processing can be executed for the file ID [0x0001] in thepartition identified by the partition manager code (PMC1), and that theaccess mode [Read] processing can be executed for the file ID: 0x0002 inthe partition identified by the partition manager code (PMC2).

[1238] In this case, the file access unit (R/W: reader/writer) 780generates a command and sends it to the device. Upon receiving the dataread command: Read Command (0x0002) for the data ID: [0x0002], thedevice checks the entry of the file open table, identifies that theaccess mode [Read] processing can be executed for the file ID: 0x0002,and executes the reading processing. The device then sends the read datato the file access unit.

[1239] The file access unit (R/W: reader/writer) 780 also generates acommand, and sends it to the device. Upon receiving the data encryptioncommand for the file ID [0x0001] [Encryption Command (0x0001, Data)],the device checks the entry of the file open table, identifies that theaccess mode [encryption/decryption processing: Enc&Dec] processing forthe file ID [0x0001] can be executed, and executes the encryptionprocessing. The device then sends the encrypted data [Encryption Data]to the file access unit (R/W: reader/writer) 780.

[1240] As discussed above, when a plurality of service permissiontickets (SPTs) (see FIG. 28) that each specify the processing for asingle file is used rather than a service permission ticket (SPT) (seeFIG. 31) that specifies the target file, data to be encrypted is read.Accordingly, the number of data transfer operations between the fileaccess unit 780 and the device is increased, and the data is readoutside the device without being encrypted.

[1241] In contrast, a plurality of file identifiers for identifying aplurality of data files to be accessed are included in the servicepermission ticket (SPT) (see FIG. 31). Among the plurality of fileidentifiers, one identifier may be set as the target file identifier,and read or write permission data for the target file is stored. As theaccess mode for the other data file, encryption processing using anencryption key stored in the data file is set. With this configuration,the memory-loaded device receives the service permission ticket (SPT)from the access unit, and executes the reading of the target file andthe encryption processing using the encryption key according to thedesignated access mode. Accordingly, the memory-loaded device is able toexecute internal encryption processing within the device. It is alsopossible to prevent the data from being output outside the devicewithout being encrypted.

[1242] The ticket issuing means for issuing the service permissionticket (SPT) is the ticket issuing means managed by the partitionmanager, which is the entity managing the memory area of thememory-loaded device. By individually issuing the service permissiontickets (SPTs) in which various access modes are set according to theaccess units, different access modes can be executed according to theaccess units.

[1243] (Usage Mode of Session Key)

[1244] Most of the data sent and received between the file access unitand the device are data that have to be prevented from being leaked toan external source, such as user information of the device or billinginformation. Accordingly, the data sent and received between the fileaccess unit and the device may preferably be encrypted, and MAC (MessageAuthentication Code) may be added to the data as the tampering checkvalue.

[1245] For data encryption, a session key generated in the mutualauthentication between the file access unit and the device can be used.As discussed above, the mutual authentication includes deviceauthentication for the device and partition authentication for eachpartition. When making an access to a file created in the partition, theencryption key is used for data transfer. There are several types ofencryption keys.

[1246] For example, as shown in FIG. 85, between the device 100 and anaccess unit 800, there are a session key Ksesl generated by deviceauthentication, a session key Kses2 generated by partitionauthentication with a partition corresponding to the partition managercode (PMC1), and a session key Kses3 generated by partitionauthentication with a partition corresponding to the partition managercode (PMC2).

[1247] These session keys are stored in the authentication table (seeFIGS. 51 and 52), which is generated during the mutual authentication,until a session is cleared.

[1248] The device and the reader/writer (a PC or another communicationunit), which serves as the device access unit that communicates with thedevice, determine in advance which session key is to be used forencryption communication as the rules, and the session key can beemployed according to the determined rules.

[1249] It is now assumed that access is allowed to files in a pluralityof different partitions, on condition that partition authentication hasbeen performed for each of the partitions, or device authentication hasbeen conducted. In this case, a single integrated session key is createdfrom a plurality of session keys obtained as a result of a plurality ofauthentication processings, and communication data for the access unitis encrypted based on the integrated session key.

[1250] One of the methods for creating the integrated session key is asfollows. When a plurality of session keys Kses1 through KsesN aregenerated by the mutual authentication processings between the deviceand the reader/writer (a PC or another communication unit), which servesas the device access unit that communicates with the device, anexclusive OR (ex. 8-byte processing) is performed on the plurality ofsession keys Kses1 through KsesN, and the calculation result is used asthe encryption session key for the communication data. That is, Ksescalculated by:

[1251] Kses=Kses XOR Kses2 XOR Kses3 . . .

[1252] XOR: exclusive OR processing (ex. 8-byte processing) is used asthe session key.

[1253] Between the device and the reader/writer (a PC or anothercommunication unit) as the device access unit that communicates with thedevice, the rule is predetermined in which an exclusive OR is performedon the session keys stored in both authentication tables, and theresulting output value is used as the session key. The session key isthen calculated based on this rule, and is used for encrypting thecommunication data. Similarly, a different session key shared during themutual authentication, for example, a session key generated during thepublic key authentication, or session-key generated data, for example,the lower 64 bits of the Y coordinate, can be used for adding a MACvalue to the communication data during the session. This MAC value maybe sent together with the communication data (may be encrypted data),and the MAC verification is performed by the receiving side, therebypreventing data from being tampered with in the communication channel.The MAC generation and verification has been discussed with reference toFIG. 59.

[1254] Alternatively, the following rule may be set: among the pluralityof session keys Kses1 through KsesN obtained by the mutualauthentication processings between the device and the reader/writer (aPC or another communication unit), which serves as the device accessunit that communicates with the device, one key (ex. the latest sessionkey) is selected, and the subsequent communication processing isperformed by using this key as the data encryption key. Then, thesession key is selected for encrypting the communication data accordingto this rule.

[1255] The above-described calculation or selection by using theplurality of session keys can be applied not only to the encryptioncommunication between the file access unit and the device, but also tothe encryption communication between any ticket (PRT, FRT, SPT, or DUT)user (the unit that performs data communication with the device, such asthe reader/writer as the device access unit) and the device, when aplurality of session keys are generated by mutual authentication. Themethod for creating the session key, i.e., the calculation or theselection among the plurality of session keys, may be predetermined asthe rule between each ticket user and the device, and then, each ticketuser and the device perform processing after confirming the rule.Alternatively, the rule may be recorded in each ticket.

[1256] An example of the typical procedure of the access processing(step S857 or 869 in the processing flow of FIG. 79) performed by thefile access unit on the device is described below with reference toFIGS. 86 and 87.

[1257] The processing when access is made to a single file (Normal) isdiscussed with reference to FIG. 86, and the processing when access ismade to a plurality of files (Combination) is discussed with referenceto FIG. 87.

[1258] A description is first given of the processing when access ismade to a single file (Normal) with reference to FIG. 86. In the flow ofFIG. 86, the processing of the file access unit is shown at the leftside, and the processing of the device (see FIG. 5) is shown at theright side. In the file access processing, when performing data transferbetween the file access unit and the device, data is encrypted by thesession key Kses obtained by the mutual authentication processing, orthe session key which is calculated or selected from a plurality ofsession keys, and tamper-checking MAC is generated and verified.

[1259] In step S891, the file access unit sends an access command to thedevice. This command is a command specifying the access file ID and theaccess mode, and may be, for example, a file ID [0x0002] data readcommand: Read Command (0x0002) or a file ID [0x0001] encryption command[Encryption Command (0x0001)], which has been discussed with referenceto FIG. 83.

[1260] Upon receiving the command from the file access unit (S901), thedevice determines whether the file ID and the access mode contained inthe command are recorded as an entry accepted in the file open table(S902). If there is no entry of the file ID and the access modecorresponding to the command in the file open table, the device does notexecute the processing in accordance with the command, and sends anaccess error to the file access unit (S908).

[1261] If there is an entry of the file ID and the access modecorresponding to the command in the file open table, in step S903, thedevice refers to the file access authentication type (AcceptableAuthentication type: the authentication type specified when access ismade to a specific file) recorded in the file definition block (FDB)(see FIG. 24) of the corresponding partition in the device memory, anddetermines the authentication level required for executing the accesscommand for the access file (whether the public key authentication isrequired).

[1262] If it is found in step S903 that the file access authenticationtype (Acceptable Authentication Type) of the file definition block (FDB)indicates that the public key authentication is required, it isdetermined in step S904 whether the public key authentication has beenconducted as the authentication level required for the access command.If the authentication has not been conducted, the processing inaccordance with the command is not executed, and sends an access errorto the file access unit (S908). A determination as to whether theauthentication has been conducted can be made based on theauthentication table (see FIG. 51), which has been set in the mutualauthentication.

[1263] If it is determined in step S903 that the file accessauthentication type (Acceptable Authentication Type) of the filedefinition block (FDB) indicates that the public key authentication isrequired, and if it is determined in step S904 that the public keyauthentication has been conducted, or if it is determined that the fileaccess authentication type (Acceptable Authentication Type) of the filedefinition block (FDB) indicates that the public key authentication isnot required, the process proceeds to step S905. In step S905, thedevice refers to the file access verification type (AcceptableVerification Type: the verification type specified when access is madeto a specific file) recorded in the file definition block (FDB) (seeFIG. 24) of the corresponding partition in the device memory, anddetermines the verification level required for executing the accesscommand for the access file (whether the public-key verification isrequired).

[1264] If it is found in step S905 that the file access verificationtype (Acceptable Verification Type) of the file definition block (FDB)indicates that the public-key ticket verification is required, it isdetermined in step S906 whether the public-key ticket verification hasbeen conducted at the verification level required for the accesscommand. If the verification has not been conducted, the device does notexecute the processing in accordance with the command, and sends anaccess error to the file access unit (S908).

[1265] If it is found in step S905 that the file access verificationtype (Acceptable Verification Type) of the file definition block (FDB)indicates that the public-key ticket verification is required, and if itis determined in step S906 that the public-key ticket verification hasbeen conducted, or if the file access verification type (AcceptableVerification Type) of the file definition block (FDB) indicates that thepublic-key ticket verification is not required, the process proceeds tostep S907. In step S907, the device executes the processing of theaccess command received from the file access unit, and sends a result tothe file access unit.

[1266] Upon receiving the access command result (S892), the file accessunit determines whether another file access is to be made (S893). Ifanother file access is made, step S891 and the subsequent steps arerepeated, and if another file access is not made, the process iscompleted.

[1267] The processing when access is made to a plurality of files(Combination) is described below with reference to FIG. 87. In the flowof FIG. 87, the processing of the file access unit is shown at the leftside, and the processing of the device (see FIG. 5) is shown at theright side. In the file access processing, when performing data transferbetween the file access unit and the device, data is encrypted by usingthe session Key Kses obtained in the mutual authentication processing,or the session key calculated or selected from a plurality of sessionkeys, and tamper-checking MAC is generated and verified.

[1268] In step S911, the file access unit sends an access command to thedevice. This command is a command specifying the access file ID(source), the access target file ID, and the access mode, and may be,for example, a command [Internal Encryption Command (0x0001, 0x0002)specifying the execution of the internal encryption processing for thesource file ID [0x0002] by using the key of the target file ID [0x0001],as has been discussed with reference to FIG. 84.

[1269] Upon receiving the command from the file access unit (S921), thedevice determines whether this access command is included in the entryof the target file ID of the file open table (S922). If the accesscommand is included in the entry of the target file ID of the file opentable, the device does not execute the processing in accordance with thecommand, and sends an access error to the file access unit (S934).

[1270] If the access command is included in the entry of the target fileID of the file open table, in step S923, the device refers to the fileaccess authentication type (Acceptable Authentication Type: theauthentication type specified when access is made to a specific file)recorded in the file definition block (FDB) (see FIG. 24) of thecorresponding partition in the device memory, and determines theauthentication level required for executing the access command for theaccess target file (whether the public key authentication is required).

[1271] If it is found in step S923 that the file access authenticationtype (Acceptable Authentication Type) of the file definition block (FDB)set for the access target file indicates that the public keyauthentication is required, it is determined in step S924 whether thepublic key authentication at the authentication level required for theaccess command has been conducted. If the authentication has not beenconducted, the device does not execute the processing in accordance withthe command, and sends an access error to the file access unit (S934). Adetermination as to whether the authentication has been conducted can bemade based on the authentication table (see FIG. 51) which has been setin the mutual authentication.

[1272] If it is found in step S923 that the file access authenticationtype (Acceptable Authentication Type) of the file definition block (FDB)set for the access target file indicates that the public keyauthentication is required, and if it is determined in step S924 thatthe public key authentication has been conducted, or if it is determinedthat the file access authentication type (Acceptable AuthenticationType) of the file definition block (FDB) indicates that the public keyauthentication is not required, the process proceeds to step S925. Instep S925, the device refers to the file access verification type(Acceptable Verification Type: the verification type specified whenaccess is made to a specific file) recorded in the file definition block(FDB) (see FIG. 24) of the corresponding partition in the device memory,and determines the verification level required for executing the accesscommand for the access target file (whether the public-key verificationis required).

[1273] If it is determined in step S925 that the file accessverification type (Acceptable Verification Type) of the file definitionblock (FDB) set for the access target file indicates that the public-keyticket verification is required, it is determined in step S926 whetherthe public-key ticket verification at the verification level requiredfor the access command has been conducted. If the verification has notbeen conducted, the device does not execute the processing in accordancewith the command, and sends an access error to the file access unit(S934).

[1274] If it is found in step S925 that the file access verificationtype (Acceptable Verification Type) of the file definition block (FDB)set for the access target file indicates that the public-key ticketverification is required, and if it is determined in step S926 that thepublic-key ticket verification has been conducted, or if it isdetermined that the file access verification type (AcceptableVerification Type) of the file definition block (FDB) indicates that thepublic-key ticket verification is not required, the process proceeds tostep S927. In step S927, the device checks, based on the command, thefile access type (Read/Write) designated by the target file ID containedin the access command.

[1275] The device determines whether the file designated by the sourcefile ID contained in the command received from the file access unit isopened for the access type (Read/Write) contained in the access command(S928). If the access type (Read/Write) for executing the command is notcontained in the file open table, the device does not execute theprocessing in accordance with the command, and sends an access error tothe file access unit (S934).

[1276] If the access type (Read/Write) corresponding to the command iscontained in the file open table, in step S929, the device refers to thefile access authentication type (Acceptable Authentication Type: theauthentication type designated when access is made to a specific file)recorded in the file definition block (FDB) (see FIG. 24) of thecorresponding partition in the device memory, and determines theauthentication level for executing the access command for the accesssource file (whether the public key authentication is required).

[1277] If it is found in step S929 that the file access authenticationtype (Acceptable Authentication Type) of the file definition block (FDB)set for the access source file indicates that the public keyauthentication is required, it is determined in step S930 whether thepublic key authentication at the authentication level required for theaccess command has been conducted. If the authentication has not beenconducted, the device does not execute the processing in accordance withthe command, and send an access error to the file access unit (S934). Adetermination as to whether the authentication has been conducted can bemade based on the authentication table (see FIG. 51) which has been setin the mutual authentication.

[1278] If it is determined in step S929 that the file accessauthentication type (Acceptable Authentication Type) of the filedefinition block (FDB) set for the access source file indicates that thepublic key authentication is required, and if it is determined in stepS930 that the public key authentication has been conducted, or if thefile access authentication type (Acceptable Authentication Type) of thefile definition block (FDB) indicates that the public key authenticationis not required, the process proceeds to step S931. In step S931, thedevice refers to the file access verification type (AcceptableVerification Type: the verification type designated when access is madeto a specific file) recorded in the file definition block (FDB) of thecorresponding partition in the device memory, and determines theverification level required for executing the access command for theaccess source file (whether the public key verification is required).

[1279] If it is found in step S931 that the file access verificationtype (Acceptable Verification Type) of the file definition block (FDB)set for the access source file indicates that the public-key ticketverification is required, it is determined in step S932 whether thepublic-key ticket verification at the verification level required forthe access command has been conducted. If the verification has not beenconducted, the device does not execute the processing in accordance withthe command, and sends an access error to the file access unit (S934).

[1280] If it is found in step S931 that the file access verificationtype (Acceptable Verification Type) of the file definition block (FDB)set for the access source file indicates that the public-key ticketverification is required, and if it is determined in step S932 that thepublic-key ticket verification has been conducted, or if the file accessverification type (Acceptable Verification Type) of the file definitionblock (FDB) indicates that the public-key verification is not required,the process proceeds to step S933. In step S933, the device executes theprocessing for the access command received from the file access unit,and sends a result to the file access unit.

[1281] Upon receiving the access command result (S912), the file accessunit determines whether another file access is to be made (S913), and ifanother file access is made, step S911 and the subsequent steps arerepeated. If another file access is not made, the process is completed.

[1282] The above-described file access processing has been described,assuming that the data designated by a single file structure is storedin the file. However, data having different file structures may bestored in a single file, so that the processing similar to theabove-described sequential processing for a plurality of files can beexecuted by a single command for a single file.

[1283]FIG. 88 illustrates the configuration in which the sequentialprocessing is performed on data in a single file by a single command fora single file.

[1284] As shown in FIG. 88, the file is an e-money file, which is formedof [Purse] as billing data, [Log] as usage log data, and [Key] as keydata for encrypting or decrypting the data.

[1285] For example, as shown in FIG. 88(a), a deposit command isspecified, and two processings can be executed: X yen is added to[Purse] as the billing data in the file (S941); and also, informationthat X yen has been added to [Purse] is written into [Log] as the usagelog data in the file (S942).

[1286] The following type of access permission ticket (SPT) specifying acomposite file is generated. The above-described money-deposit commandis defined as the permission command (see FIG. 30) for the deposit typeof the above-described file access mode (see FIG. 29), [Deposit] is setin the file access mode of the access permission ticket, and e-money isset as the file ID. After sending this access permission ticket to thedevice from the file access unit, the deposit billing data is senttogether with the deposit command, thereby making it possible to performthe sequential processing for the data in a single file in the device,as shown in FIG. 88(a).

[1287] Also, as shown in FIG. 88(b), a receipt creation command (MakeReceipt Command) is defined, and then, three-step processing can beperformed: X yen is subtracted from [Purse] as the billing data in thefile (S945); information that X yen has been subtracted from [Purse] iswritten into [Log] as the usage log data in the file (S946); and [Key]as encryption key data is added to [Log], and [Log] is sent with thesignature (S947).

[1288] In this case, the following access permission ticket (SPT)specifying a composite file is generated. The above-described receiptcreation command (Make Receipt Command) is defined as the permissioncommand (see FIG. 30) corresponding to the withdraw type of the fileaccess mode (see FIG. 29); [Withdraw] is set in the file access mode ofthe access permission ticket, and e-money is set as the file ID. Aftersending this access permission ticket to the device from the file accessunit, withdraw billing data is sent together with the make receiptcommand, thereby making it possible to perform the sequential processingfor the data in a single file in the device, as shown in FIG. 88(b).

[1289] In this manner, when the file specified in the service permissionticket (SPT) is a composite file, the device selects the file to beprocessed indicated in the command received from the access unit fromthe composite file, and executes the processing. If the data processingcommand from the access unit is a sequential processing commandincluding a set of processings, the device selects the file to beprocessed indicated in each command contained in the sequentialprocessing command from the composite file specified in the servicepermission ticket (SPT), and sequentially performs the processings.

[1290] [B4.7. Processing Procedure in Each Access Processing MethodUsing Service Permission Ticket (SPT]

[1291] In the above-described access-processing-file settingregistration processing using the service permission ticket (SPT),mutual authentication is conducted between the device and thereader/writer as the device access unit, i.e., a service permissionticket (SPT) user, managed by the partition manager, and then, fileaccess is made based on the service permission ticket (SPT). There aretwo types of mutual authentication modes, i.e., the public-key mutualauthentication and the common-key mutual authentication. There are alsotwo types of ticket (SPT) verification processing modes, i.e., thesignature verification of the public key system and the MAC checking ofthe common key system. That is, the following four processing modes areprimarily provided:

[1292] (A) mutual authentication (public key) and ticket (SPT)verification (public key);

[1293] (B) mutual authentication (public key) and ticket (SPT)verification (common key);

[1294] (C) mutual authentication (common key) and ticket (SPT)verification (common key); and

[1295] (D) mutual authentication (common key) and ticket (SPT)verification (public key).

[1296] The four processing modes are briefly discussed with reference tothe drawings by emphasizing the data transfer processing executed amongthe entities, such as the certificate authority (CA(PM)), the partitionmanager (PM), the reader/writer as the device access unit, i.e., the SPTticket user, and the device.

[1297] (A) Mutual Authentication (Public Key) and Ticket (SPT)Verification (Public Key)

[1298] A description is first given, with reference to FIG. 89, of thedata transfer performed among the entities when the public key system isused for mutual authentication processing and the public key system isused for ticket (SPT) verification.

[1299] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 89. The processing is described belowaccording to the numbers.

[1300] (1) Issuing of Public Key Certificate (Cert. PM) of PartitionManager (PM)

[1301] In response to a request from the partition manager (PM), thepublic key certificate (Cert. PM) of the partition manager (PM) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Inthis configuration, the partition manager serves as the servicepermission ticket issuing means (SPT Issuer), and the public keycertificate of the partition manager (PM) is used as the public keycertificate of the service permission ticket issuing means (SPT Issuer).

[1302] (2) Issuing of Public Key Certificate (Cert. RW) of Reader/Writeras Device Access Unit, i.e., Service Permission Ticket User (SPT User)

[1303] In response to a request from the reader/writer (R/W), i.e., theservice permission ticket user (SPT User: and more specifically, areader/writer (R/W) as the device access unit that sends a ticket to thedevice), the public key certificate (Cert. R/W) of the servicepermission ticket user (SPT User) is issued by the partition certificateauthority (CA(PAR)) according to a certificate issuing procedure via theregistration authority (RA). The partition manager may serve as theservice permission ticket user (SPT User), in which case, the public keycertificate of the partition manager (PM) can be used as the public keycertificate of the service permission ticket user (SPT User).

[1304] (3) Creation Processing of Service Permission Ticket (SPT)

[1305] The service permission ticket (SPT) is created by the servicepermission ticket (SPT) issuing means (SPT Ticket Issuer) managed by thepartition manager. In this case, for creating and verifying thepublic-key signature, the signature is created by the private key of theservice permission ticket issuing means (SPT Ticket Issuer) (see FIG.12), and is added to the SPT.

[1306] (4) Supply of SPT and Partition-Manager Public Key Certificate(Cert. PM) of Service Permission Ticket Issuing Means (SPT TicketIssuer) to Reader/Writer as Device Access Unit, i.e., Service PermissionTicket User (SPT Issuer)

[1307] The service permission ticket (SPT) issued by the servicepermission ticket issuing means (SPT Ticket Issuer) managed by thepartition manager is supplied to the reader/writer (R/W) as the deviceaccess unit, i.e., the service permission ticket user (SPT User),together with the partition-manager public key certificate (Cert. PM) ofthe service permission ticket issuing means (SPT Ticket Issuer).

[1308] (5) Mutual Authentication between Reader/Writer (R/W) as DeviceAccess Unit and Device

[1309] The reader/writer, i.e., the service permission ticket user (SPTUser), sends the public key certificate (Cert. RW) of the reader/writer(R/W) as the ticket user (SPT User) to the device to which file accessis to made according to the service permission ticket (SPT) issued bythe service permission ticket issuing means (SPT Ticket Issuer), therebyperforming public-key mutual authentication (see FIG. 50).

[1310] (6) Supply of SPT and Partition-Manager Public Key Certificate(Cert. PM) of Service Permission Ticket Issuing Means (SPT TicketIssuer) to Device

[1311] After the mutual authentication has been successfully conductedbetween the reader/writer (R/W) as the device access unit and thedevice, the reader/writer as the ticket user (SPT User) sends theservice permission ticket (SPT) and the partition-manager public keycertificate (Cert. PM) of the service permission ticket issuing means(SPT Ticket Issuer) to the device.

[1312] The device has checked the following factors concerning thereceived service permission ticket (SPT): (1) the partition-managerpublic key certificate (Cert. PM) of the ticket issuer is an authorizedpublic key certificate (CERT) without being tampered with; (2) the coderecorded in the option area of the public key certificate (CERT PM) ofthe ticket issuer coincides with (SPTIC) recorded in the FDB (FileDefinition Block) in the device; (3) the ticket issuing means (TicketIssuer) is not revoked; and (4) the ticket has not been tampered with byverifying the signature of the received ticket (SPT). The SPT user (areader/writer as the device access unit) is also verified (see FIGS. 57and 58) by verifying whether mutual authentication has been conducted bychecking whether the identifier, the category, or the serial (SN) name(DN) of the SPT user (a reader/writer as the ticket user) stored in theSPT ticket coincides with the identifier, the category, or the serial(SN) name (DN) recorded as the ID data (DN) of the public keycertificate (Cert. RW) of the ticket user (SPT User).

[1313] (7) File Access

[1314] The device makes access to the corresponding file according tothe rules indicated in the service permission ticket (SPT).

[1315] By performing the above-described processing, the file accessprocessing in accordance with the mutual authentication (public key) andticket (SPT) verification (public key) can be executed.

[1316] (B) Mutual Authentication (Public Key) and Ticket (SPT)Verification (Common Key)

[1317] A description is now given, with reference to FIG. 90, of thedata transfer performed among the entities when the public key system isused for mutual authentication processing and the common key system isused for ticket (SPT) verification.

[1318] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 90. The processing is described belowaccording to the numbers.

[1319] (1) Issuing of Public Key Certificate (Cert. RW) of Reader/Writeras Device Access Unit, i.e., Service Permission Ticket User (SPT User)

[1320] In response to a request from the reader/writer (R/W), i.e., theservice permission ticket user (SPT User: and more specifically, thereader/writer (R/W) as the device access unit that sends a ticket to thedevice), the public key certificate (Cert. R/W) of the servicepermission ticket user (SPT User) is issued by the partition certificateauthority (CA(PAR)) according to a certificate issuing procedure via theregistration authority (RA). The partition manager may serve as theservice permission ticket user (SPT User), in which case, the public keycertificate of the partition manager (PM) can be used as the public keycertificate of the service permission ticket user (SPT User).

[1321] (2) Creation Processing of Service Permission Ticket (SPT)

[1322] The service permission ticket (SPT) is created by the servicepermission ticket (SPT) issuing means (SPT Ticket Issuer) managed by thepartition manager. In this case, MAC (Message Authentication Code) (seeFIG. 59) as the common-key verification value is added to the SPT.

[1323] (3) Supply of SPT to Reader/Writer as Device Access Unit, i.e.,Service Permission Ticket User (SPT User)

[1324] The service permission ticket (SPT) issued by the servicepermission ticket issuing means (SPT Ticket Issuer) managed by thepartition manager is supplied to the reader/writer (R/W) as the deviceaccess unit, i.e., the service permission ticket user (SPT User).

[1325] (4) Mutual Authentication Between Reader/Writer (R/W) and Device

[1326] The reader/writer as the device access unit, i.e., the servicepermission ticket user (SPT User), sends the public key certificate(Cert. RW) of the reader/writer (R/W) as the ticket user (SPT User) tothe device to which file access is to made according to the servicepermission ticket (SPT) issued by the service permission ticket issuingmeans (SPT Ticket Issuer), thereby performing public-key mutualauthentication (see FIG. 50).

[1327] (5) Supply of SPT to Device

[1328] After the mutual authentication has been successfully conductedbetween the reader/writer (R/W) as the device access unit and thedevice, the reader/writer, i.e., the service permission ticket user (SPTUser), sends the service permission ticket (SPT) to the device. Thedevice performs the MAC checking processing for the received servicepermission ticket (SPT) so as to verify the SPT issuer. The SPT user (areader/writer as the device access unit) is also verified (see FIGS. 57and 58) by verifying whether mutual authentication has been conducted bychecking whether the identifier, the category, or the serial (SN) name(DN) of the SPT user (a reader/writer as the ticket user) stored in theSPT ticket coincides with the identifier, the category, or the serial(SN) name (DN) recorded as the ID data (DN) of the public keycertificate (Cert. RW) of the ticket user (SPT User).

[1329] (6) File Access

[1330] The device makes access to the corresponding file according tothe rules indicated in the service permission ticket (SPT).

[1331] By performing the above-described processing, the file accessprocessing in accordance with the mutual authentication (public key) andticket (SPT) verification (common key) can be executed.

[1332] (C) Mutual Authentication (Common Key) and Ticket (SPT)Verification (Common Key)

[1333] A description is now given, with reference to FIG. 91, of thedata transfer performed among the entities when the common key system isused for mutual authentication processing and the common key system isused for ticket (SPT) verification.

[1334] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 91. The processing is described belowaccording to the numbers.

[1335] (1) Creation Processing of Service Permission Ticket (SPT)

[1336] The service permission ticket (SPT) is created by the servicepermission ticket (SPT) issuing means (SPT Ticket Issuer) managed by thepartition manager. In this case, MAC (Message Authentication Code) (seeFIG. 59) as the common-key verification value is added to the SPT.

[1337] (2) Supply of SPT to Service Permission Ticket User (SPT User)

[1338] The service permission ticket (SPT) issued by the servicepermission ticket issuing means (SPT Ticket Issuer) managed by thepartition manager is supplied to the reader/writer as the device accessunit, i.e., the service permission ticket user (SPT User).

[1339] (3) Mutual Authentication Between Reader/Writer (R/W) as DeviceAccess Unit and Device

[1340] The reader/writer (R/W) as the device access unit, i.e., theservice permission ticket user (SPT User), performs common-key mutualauthentication (see FIGS. 53 and 54) with the device that is to create afile according to the service permission ticket (STP) issued by theservice permission ticket issuing means (SPT Ticket Issuer).

[1341] (4) Supply of SPT to Device

[1342] After the mutual authentication has been successfully conductedbetween the reader/writer (R/W) as the device access unit and thedevice, the reader/writer, i.e., the service permission ticket user (SPTUser), sends the service permission ticket (SPT) to the device. Thedevice performs the MAC checking processing for the received servicepermission ticket (SPT) so as to verify the SPT issuer. The SPT user (areader/writer as the device access unit) is also verified (see FIGS. 57and 58) by verifying whether mutual authentication has been conducted bychecking whether the identifier of the SPT user (a reader/writer as theticket user) stored in the SPT ticket coincides with the identifier ofthe ticket user (SPT User).

[1343] (5) File Access

[1344] The device makes access to the corresponding file according tothe rules indicated in the service permission ticket (SPT).

[1345] By performing the above-described processing, the file accessprocessing in accordance with the mutual authentication (common key) andticket (SPT) verification (common key) can be executed.

[1346] (D) Mutual Authentication (Common Key) and Ticket (SPT)Verification (Public Key)

[1347] A description is now given, with reference to FIG. 92, of thedata transfer performed among the entities when the common key system isused for mutual authentication processing and the public key system isused for ticket (SPT) verification.

[1348] The data transfer is performed among the entities in the order ofthe numbers shown in FIG. 92. The processing is described belowaccording to the numbers.

[1349] (1) Issuing of Public Key Certificate (Cert. PM) of PartitionManager (PM)

[1350] In response to a request from the partition manager (PM), thepublic key certificate (Cert. PM) of the partition manager (PM) isissued by the partition certificate authority (CA(PAR)) according to acertificate issuing procedure via the registration authority (RA). Inthis configuration, the partition manager serves as the servicepermission ticket issuing means (SPT Issuer), and the public keycertificate of the partition manager (PM) is used as the public keycertificate of the service permission ticket issuing means (SPT Issuer).

[1351] (2) Creation Processing of Service Permission Ticket (SPT)

[1352] The service permission ticket (SPT) is created by the servicepermission ticket (SPT) issuing means (SPT Ticket Issuer) managed by thepartition manager. In this case, for creating and verifying thepublic-key signature, the signature is created by the private key of theservice permission ticket issuing means (SPT Ticket Issuer) (see FIG.12), and is added to the SPT.

[1353] (3) Supply of SPT and Partition-Manager Public Key Certificate(Cert. PM) of Service Permission Ticket Issuing Means (SPT TicketIssuer) to Reader/Writer as Device Access Unit, i.e., Service PermissionTicket User (SPT Issuer)

[1354] The service permission ticket (SPT) issued by the servicepermission ticket issuing means (SPT Ticket Issuer) managed by thepartition manager is supplied to the service permission ticket user (SPTUser), namely, the unit (ex., the reader/writer as the device accessunit) that sends the ticket to the device, together with thepartition-manager public key certificate (Cert. PM) of the servicepermission ticket issuing means (SPT Ticket Issuer).

[1355] (4) Mutual Authentication Between Reader/Writer (R/W) as DeviceAccess Unit and Device

[1356] The reader/writer as the device access unit, i.e., the servicepermission ticket user (SPT User), performs common-key mutualauthentication (see FIGS. 53 and 54) with the device that is to makefile access according to the service permission ticket (STP) issued bythe service permission ticket issuing means (SPT Ticket Issuer).

[1357] (5) Supply of SPT and Partition-Manager Public Key Certificate(Cert. PM) of Service Permission Ticket Issuing Means (SPT TicketIssuer) to Device

[1358] After the mutual authentication has been successfully conductedbetween the reader/writer (R/W) and the device, the reader/writer as thedevice access unit, i.e., the service permission ticket user (SPT User),sends the service permission ticket (SPT) and the partition-managerpublic key certificate (Cert. PM) of the service permission ticketissuing means (SPT Ticket Issuer) to the device.

[1359] The device has checked the following factors concerning thereceived service permission ticket (SPT): (1) the partition-managerpublic key certificate (Cert. PM) of the ticket issuer is an authorizedpublic key certificate (CERT) without being tampered with; (2) the coderecorded in the option area of the partition-manager public keycertificate (CERT PM) of the ticket issuer coincides with ticket issuingmeans code (SPTIC) recorded in the FDB (File Definition Block) in thedevice; (3) the ticket issuing means (Ticket Issuer) is not revoked; and(4) the ticket has not been tampered with by verifying the signature ofthe received ticket (SPT). The SPT user (a reader/writer) is alsoverified (see FIGS. 57 and 58) by determining whether mutualauthentication has been conducted by checking whether the identifier ofthe SPT user (a reader/writer as the ticket user) stored in the SPTticket coincides with the identifier of the ticket user (SPT User).

[1360] (6) File Access

[1361] The device makes access to the corresponding file according tothe rules indicated in the service permission ticket (SPT).

[1362] By performing the above-described processing, the file accessprocessing in accordance with the mutual authentication (common key) andticket (SPT) verification (public key) can be executed.

[1363] [B5. Device Data Updating Processing Using Data Update Ticket(DUT)]

[1364] The data updating processing using the data update ticket (DUT)is described below. The data update ticket (DUT) is the access controlticket used for performing updating processing of various data stored inthe device. By using a DUT issued by authorized data update ticket (DUT)issuing means (Ticket Issuer), the device is accessed by the ticket user(ex. a reader/writer as the device access unit) according to theprocedure recorded in the DUT, thereby making it possible to performdata processing within the restriction recorded in the DUT.

[1365] As discussed above, the data update ticket (DUT) includes aticket DUT (DEV) used for updating data items managed by the devicemanager and a ticket DUT (PAR) (see FIG. 32) used for updating dataitems in a partition managed by a partition manager.

[1366] A description is now given of performing data updating processingby using the data update ticket (DUT) for the data stored in the devicewith reference to the flow of FIG. 93 and the other drawings. The dataupdating processing includes mutual authentication processing (deviceauthentication or partition authentication) between the device and thereader/writer as the device access unit that performs data updating, andintegrity verification processing for the data update ticket (DUT).

[1367] The data updating processing flow of FIG. 93 is discussed below.In FIG. 93, the processing of the data updating unit is shown at theleft side, and the processing of the device (see FIG. 5) is shown at theright side. The data updating unit is the unit (ex. a reader/writer or aPC as the device access unit) which is able to read and write data fromand into the device, and corresponds to the reader/writer as the deviceaccess unit shown in FIG. 10. An overview of the data updatingprocessing is described below with reference to FIG. 93, and details ofthe data updating operation contained in the data updating processingare discussed below with reference to the flow of FIG. 94.

[1368] In steps S951 and S960 of FIG. 93, mutual authenticationprocessing is first performed between the data updating unit and thedevice. Between the two means for performing data sending and receiving,it is first checked with each other whether they are authorized datacommunication means, and then, data transfer is performed according tothe necessity. The mutual authentication processing is to check whetherthe other party is authorized data communication means. In the mutualauthentication processing, a session key is created, and data isencrypted by using the session key as the common key. Then, the data istransferred.

[1369] As the mutual authentication processing, the partitionauthentication is performed, as has been discussed in the section of thepartition creation/deletion processing. A common key system or a publickey system is used for the data updating processing. The mutualauthentication is similar to the processing discussed with reference toFIGS. 48 through 56, and an explanation thereof is thus omitted.

[1370] The processing to be executed as the mutual authenticationprocessing is determined by:

[1371] Authentication Type: the type of mutual authentication (publickey authentication, common key authentication, or either type (Any)) ofthe device of the data update ticket (DUT) (see FIG. 32) to be used.

[1372] If the authentication processing has failed (No in S952 or S961),it means that it cannot be determined that the data updating unit andthe device are authorized unit and device, and the subsequent processingis not executed, and the process is terminated as an error.

[1373] If the authentication processing has succeeded, the data updatingunit sends the data update ticket (DUT) to the device. The data updateticket (DUT) is the ticket issued by the data update ticket (DUT)issuing means (DUT Issuer) managed by the device manager or thepartition manager. The data update ticket (DUT) is the access controlticket for the device, and has the data format configuration shown inFIG. 32.

[1374] When sending the data update ticket (DUT) to the ticket user, thepublic key certificate (CERT_DUTI) of the data update ticket (DUT)issuing means (DUT Issuer) is also sent together if the public keysystem is employed. The attribute of the public key certificate(CERT_DUTI) of the DUT issuing means coincides with the identifier(DUTIC) of the ticket issuing means code (DUTIC_DEV) recorded inDKDB(PUB) (Device Key Definition Block) in the device or the identifier(DUTIC) of the ticket issuing means code (DUTIC_PAR) recorded inPKDB(PUB) (Partition Key Definition Block).

[1375] Upon receiving the data update ticket (DUT) (S962), the devicechecks the integrity of the received ticket (DUT) and the user (S963).The ticket verification processing can be performed by either the MACchecking of the common key system or the signature verification of thepublic key system. The user checking is to check the integrity of theunit that has sent the ticket (ticket user), and is performed bydetermining whether mutual authentication has been conducted by checkingthe consistency between the ID data of the unit to be authenticated andthe ticket user identifier (see FIG. 32) recorded in the ticket. Theseprocessings are similar to those discussed with reference to FIGS. 57through 59, as has been discussed in the processing using the partitionregistration ticket (PRT), and an explanation thereof is thus omitted.

[1376] As a result of the integrity checking for the received ticket(DUT) and the user, if it cannot be determined that the ticket and theuser are authorized ticket and user (No in S964), the device report adata update ticket (DUT) reception error to the data updating unit(S968). If it can be determined that the ticket and the user areauthorized ticket and user (Yes in S964), the device updates the data(see FIG. 33) stored in the device memory according to the rulesindicated in the received data update ticket (DUT). Details of thisprocessing are described below by using a different flow.

[1377] If the data updating processing has succeeded according to thedescription in the data update ticket (DUT) (Yes in S966), the devicereports a DUT reception success to the data updating unit (S967). If thedata updating processing has failed (No in S966), the device reports aDUT reception error to the data updating unit (S968).

[1378] The data updating unit receives the DUT reception result (S954),and determines the DUT processing result. If the DUT reception resultindicates an error (No in S955), the process is terminated as an error.If the DUT reception result indicates a success (Yes in S955), a sessionclear command is sent and received (S956 and S969), and theauthentication table generated in the device is discarded (S970). Theprocess is then completed. The authentication table is the tablegenerated in the mutual authentication processing in steps S951 andS960, and has the configuration shown in FIG. 51, as has been discussedin the processing using the partition registration ticket (PRT).

[1379] As described above, the updating processing of the data stored inthe device is executed by using the data update ticket (DUT). The dataupdating operation (S965) included in the updating processing isdiscussed below with reference to FIG. 94.

[1380] The processing flow of FIG. 94 is executed in the device that hasreceived the data update ticket (DUT), and is performed after the mutualauthentication with the unit that has sent the data update ticket (DUT)has been successfully conducted and the ticket verification hassucceeded.

[1381] In step S971, the device first searches for the version of thedata to be updated from the old data code of the data update ticket(DUT). The version is recorded in the device management informationblock (see FIG. 15) if the data to be updated is the device manager code(DMC). The version is recorded in the partition management informationblock (see FIG. 20) if the data to be updated is the partition managercode (PMC). The version of the partition registration ticket (PRT)issuing means (PRT Issuer) is contained in the device definition block(see FIG. 16). The version of the revocation list (IRL DEV, CRL DEV) iscontained in the revocation list. In this manner, the storage locationof the version information is determined according to the type ofinformation, and the device searches for the version of the data to beupdated from the old data code to be updated.

[1382] Then, in step S972, the device checks the version condition [DataVersion Rule] for updating the data recorded in the data update ticket(DUT), and determines whether the version condition is set to [Any].

[1383] As discussed above, there are three types of version conditions[Data Version Rule], such as Any, Exact, and Older, when performing dataupdating. “Any” indicates that data can be updated regardless of theversion condition; “Exact” means that data can be updated when theversion value is the same as the value designated in the subsequentfiled [Data Version Condition]; and “Older” means that data can beupdated only when the new data version is newer. If the versioncondition [Data Version Rule] is Any or Older, [Data Version Condition]is not used or ignored.

[1384] If [Data Version Condition] of the data update ticket (DUT) isnot set to [Any], the processing in accordance with the versioncondition [Data Version Rule] is performed. This processing correspondsto steps S973 through S975.

[1385] In step S973, the device checks the version condition [DataVersion Rule] of the data update ticket (DUT), and determines whether itis set to [EXACT]. [Exact] means that data can be updated when theversion value is the same as the value designated in the subsequentfiled [Data Version Condition]. If the version condition [Data VersionRule] is set to [EXACT], the device determines in step S974 whether theversion of the data to be updated [Old Data] coincides with the versionvalue recorded in [Data Version Condition] of the data update ticket(DUT). If the version values coincide with each other, the processproceeds to the subsequent step, and if they are different, the processis terminated as an error without performing the updating processing.

[1386] If it is determined in step S973 that the version condition [DataVersion Rule] of the data update ticket (DUT) is not [EXACT], it shouldbe [Older]. According to the setting of [Older], data can be updatedonly when [New Data Version] indicating the version of new data [NewData] of the data update ticket (DUT) is newer than the version of datato be updated [Old Data]. In this case, it is determined in step S975whether [New Data Version] indicating the version of new data [New Data]of the data update ticket (DUT) is newer than the version of the data tobe updated [Old Data]. Only when [New Data Version] is newer, theprocess proceeds to the subsequent step. If not, the process isterminated as an error without performing the updating processing.

[1387] Then, in step S976, the device verifies [Encrypted Flag] of thedata update ticket (DUT). [Encrypted Flag] is the data indicatingwhether data to be updated is encrypted (encrypted:Encrypted/unencrypted: none). If [Encrypted Flag] indicates that thedata to be updated is unencrypted data, in step S977, the new data [NewData] of the data update ticket (DUT) is replaced by the old data to beupdated [Old Data] stored in the device memory, and the process iscompleted. If the version is added to the data to be updated, theversion of the updating data (New Data Version) stored in the dataupdate ticket (DUT) is stored in the version storage area, which is setin correspondence with the updating data in the device.

[1388] If it is determined in step S976 that [Encrypted Flag] of thedata update ticket (DUT) indicates that the data to be updated isencrypted, in step S978, the device verifies [Ticket Type] of the dataupdate ticket (DUT). [Ticket Type] indicates the type of ticket(DUT(DEV)/DUT(PAR)). DUT(DEV) indicates that the data update ticket(DUT) is a ticket for executing the updating processing of a data itemmanaged by the device manager. DUT(PAR) indicates that the data updateticket (DUT) is a ticket for executing the updating processing of a dataitem in a partition managed by the partition manager.

[1389] If [Ticket Type] indicates DUT(DEV), steps S979 through S982 areexecuted, and if [Ticket Type] indicates DUT(PAR), steps S983 throughS986 are executed.

[1390] If [Ticket Type] indicates DUT(DEV), it is determined in stepS979 whether the data represented by Old Data Code (code of the old datato be updated) indicated in the data update ticket (DUT(DEV)) isKdut_DEV1 (MAC checking key of the data update ticket (DUT)) orKdut_DEV2 (data updating encryption key) stored in the device key area(see FIG. 18).

[1391] If the data represented by the data of Old Data Code (code of theold data to be updated) indicated in the data update ticket (DUT(DEV))is Kdut_DEV1 (MAC checking key of the data update ticket (DUT)) orKdut_DEV2 (data updating encryption key) stored in the device key area(see FIG. 18), the process proceeds to step S980. In step S980, by usingKdut_DEV4 (data updating encryption key) stored in the device key area(see FIG. 18) of the device, Kdut_DEV1 and Kdut_DEV2 as the new data[New Data] stored in the data update ticket (DUT(DEV)) are decrypted,and Kdut_DUT1 and Kdut_DEV2 stored in the device key area of the deviceare overwritten by the decrypted data. Also, the version of the updatingdata (New Data Version) stored in the data update ticket (DUT(DEV)) isstored in the version storage area, which is set in correspondence withthe updating data in the device, in this case, in the device key area(see FIG. 18) of the device.

[1392] Then, in step S981, Kdut_DEV1 (MAC checking key of the dataupdate ticket (DUT) and Kdut_DUT3 (MAC checking key of the data updateticket (DUT) stored in the device key area (see FIG. 18) of the deviceare swapped, and Kdut_DEV2 (data updating encryption key) and Kdut_DEV4(data updating encryption key) are also swapped. The process is thencompleted.

[1393] By swapping Kdut_DEV1 and Kdut_DEV3 and swapping Kdut_DEV2 andKdut_DEV4, a pair of Kdut_DEV3 (MAC checking key of the data updateticket (DUT)) and Kdut_DEV4 (data updating encryption key) is alwaysmaintained to be newer versions than a pair of Kdut_DEV1 (MAC checkingkey of the data update ticket (DUT)) and Kdut_DEV2 (data updatingencryption key). It is possible to perform processing by setting thatKdut_DEV1 and Kdut_DEV2 are always to be updated.

[1394] If it is found in step S979 that the data represented by Old DataCode (code of the old data to be updated) indicated in the data updateticket (DUT) is neither Kdut_DEV1 (MAC checking key of the data updateticket (DUT)) nor Kdut_DEV2 (data updating encryption key) stored in thedevice key area (see FIG. 18), the process proceeds to step S982. Instep S982, by using Kdut_DEV2 (data updating encryption key) stored inthe device key area (see FIG. 18) of the device, the new data [New Data]stored in the data update ticket (DUT(DEV)) is decrypted, and the areaindicated by Old Data Code (code of the old data to be updated) of thedata update ticket (DUT(DEV)) is overwritten by the decrypted data. Ifthe version is added to the data to be updated, the version of theupdating data (New Data Version) stored in the data update ticket(DUT(DEV)) is stored in the version storage area, which is set incorrespondence with the updating data in the device.

[1395] If it is found in step S978 that the ticket type [Ticket Type]indicates DUT(PAR), steps S983 through S986 are executed.

[1396] If the ticket type [Ticket Type] indicates DUT (PAR), it isdetermined in step S983 whether the data represented by Old Data Code(code of the old data to be updated) indicated in the data update ticket(DUT(PAR)) is Kdut_PAR1 (MAC checking key of the data update ticket(DUT)) or Kdut_PAR2 (data updating encryption key) stored in thepartition key area (see FIG. 23).

[1397] If the data represented by Old Data Code (code of the old data tobe updated) indicated in the data update ticket (DUT (PAR)) is Kdut_PAR1(MAC checking key of the data update ticket (DUT)) or Kdut_PAR2 (dataupdating encryption key) stored in the partition key area (see FIG. 23),the process proceeds to step S984. In step S984, by using Kdut_PAR4(data updating encryption key) stored in the partition key area (seeFIG. 23) of the device, Kdut_PAR1 and Kdut_PAR2 as the new data [NewData] stored in the data update ticket (DUT(PAR)) are decrypted, andKdut_PAR1 and Kdut_PAR2 stored in the partition key area of the deviceare overwritten by the decrypted data. Also, the version of the updatingdata (New Data Version) stored in the data update ticket (DUT(PAR)) isstored in the version storage area, which is set in correspondence withthe updating data in the device, in this case, in the partition key area(see FIG. 23) of the device.

[1398] Then, in step S985, Kdut_PAR1 (MAC checking key of the dataupdate ticket (DUT)) and Kdut_PAR3 (MAC checking key of the data updateticket (DUT)) stored in the partition key area (see FIG. 23) of thedevice are swapped, and Kdut_PAR2 (data updating encryption key) andKdut_PAR4 (data updating encryption key) are swapped. The process isthen completed.

[1399] By swapping Kdut_PAR1 and Kdut_PAR3 and swapping Kdut_PAR2 andKdut_PAR4, a pair of Kdut_PAR3 (MAC checking key of the data updateticket (DUT)) and Kdut_PAR4 (data updating encryption key) is alwaysmaintained to be newer versions than a pair of Kdut_PAR1 (MAC checkingvalue of the data update ticket (DUT)) and Kdut_PAR2 (data updatingencryption key). It is thus possible to perform processing by settingthat Kdut_PAR1 and Kdut_PAR2 are always to be updated.

[1400] If it is found in step S983 that the data represented by Old DataCode (code of the old data to be updated) indicated in the data updateticket (DUT(PAR)) is neither Kdut_DEV1 (MAC checking key of the dataupdate ticket (DUT)) nor Kdut_DEV2 (data updating encryption key) storedin the partition key area (see FIG. 18), the process proceeds to stepS986. In step S986, by using Kdut_PAR2 (data updating encryption key)stored in the partition key area (see FIG. 23) of the device, the newdata [New Data] stored in the data update ticket (DUT(PAR)) isdecrypted, and the area indicated by Old Data Code (code of the old datato be updated) of the data update ticket (DUT(PAR)) is overwritten bythe decrypted data. Tf the version is added to the data to be updated,the version of updating data (New Data Version) stored in the dataupdate ticket (DUT(PAR)) is stored in the version storage area, which isset in correspondence with the updating data in the device.

[1401] The above-described processing is the data updating operationexecuted in the device based on the data update ticket.

[1402] As is seen from the above-described flow, when the data to beupdated is

[1403] Kdut_DEV1 (MAC checking key of the data update ticket (DUT)) or

[1404] Kdut_DEV2 (data updating encryption key), stored in the devicekey area, or

[1405] Kdut_PAR1 (MAC checking key of the data update ticket (DUT)) or

[1406] Kdut_PAR2 (data updating encryption key), stored in the partitionkey area,

[1407] the processing other than the normal updating processing isperformed.

[1408] A brief summary of the updating processing for Kdut_DEV1 (MACchecking key of the data update ticket (DUT)), Kdut_DEV2 (data updatingencryption key), Kdut_PAR1 (MAC checking key of the data update ticket(DUT)), and Kdut_PAR2 (data updating encryption key) is shown in FIG.95. The updating processing is described in the order from (1) to (3).Since the processing of Kdut_DEV1,2 is similar to that of Kdut_PAR1,2,the updating processing for Kdut_DEV1,2 is only discussed.

[1409] (1) After encrypting Kdut_DEV1 and Kdut_DEV2 as the new data [NewData] to be stored in the data update ticket (DUT) by using Kdut_DEV4(data updating encryption key) stored in the device key area (see FIG.18) of the device, the encrypted data is stored in the data updateticket (DUT). The data update ticket (DUT) is then sent to the device.In this case, the ticket issuer that is able to update Kdut_DEV1 andKdut_DEV2 must know Kdut_DEV3 and Kdut_DEV4.

[1410] (2) Upon receiving the data update ticket (DUT), the devicedecrypts Kdut_DEV1 and Kdut_DEV2 as the new data [New Data] stored inthe date update ticket (DUT) by using Kdut_DEV4 (data updatingencryption key) stored in the device key area of the device, andoverwrites Kdut_DEV1 and Kdut_DEV2 stored in the device key area of thedevice by the decrypted Kdut_DEV1 and Kdut_DEV2, respectively.

[1411] (3) Then, the device swaps newly stored Kdut_DEV1 (MAC checkingkey of the data update ticket (DUT)) in the device key area (see FIG.18) of the device and the previously stored Kdut_DEV3 (MAC checking keyof the data update ticket (DUT)). The device also swaps newly storedKdut_DEV2 (data updating encryption key) and the previously storedKdut_DEV4 (data updating encryption key).

[1412] By swapping Kdut_DEV1 and Kdut_DEV3 and swapping Kdut_DEV2 andKdut_DEV4, a pair of Kdut_DEV3 (MAC checking key of the data updateticket (DUT)) and Kdut_DEV4 (data updating encryption key) is alwaysmaintained to be newer versions than a pair of Kdut_DEV1 (MAC checkingvalue of the data update ticket (DUT)) and Kdut_DEV2 (data updatingencryption key). That is, Kdut_DUV1 and Kdut_DEV2 are keys that arenormally used, and Kdut_DEV3 and Kdut_DEV4 are keys that updateKdut_DEV1 and Kdut_DEV2, respectively, in the event of an emergency,which serve as backup keys to replace currently used Kdut_DEV1 andKdut_DEV2, respectively.

[1413] Kdut_DEV1 (MAC checking key of the data update ticket (DUT)) andKdut_DEV2 (data updating encryption key) are used as a pair, andKdut_DEV3 (MAC checking key of the data update ticket (DUT)) andKdut_DEV4 (data updating encryption key) are also used as a pair.

[1414] The present invention has been described in detail with referenceto a specific embodiment. It is apparent however that those who areskilled in the art are able to modify or arrange the embodiment withoutdeparting from the spirit and scope of the invention. That is, theinvention has been disclosed in an example only, and should not beinterpreted in a restricting manner. The scope of the invention shouldbe determined by taken the claims recited at the head of thespecification into consideration.

[1415] A series of processings described in this specification can beimplemented by hardware or software, or a composite constructionincluding both hardware and software. If the processings are executed bysoftware, a program in which a processing sequence is recorded may beinstalled into a memory of a computer integrated into dedicatedhardware, or the program may be installed into a general-purposecomputer which is able to execute various processings.

[1416] For example, the program may be recorded in advance in arecording medium, such as a hard disk or a ROM (Read Only Memory).Alternatively, the program may be temporarily or permanently stored(recorded) in a removable recording medium, such as a floppy disk, aCD-ROM (Compact Disc Read Only Memory), an MO (Magneto optical) disk, aDVD (Digital Versatile Disc), a magnetic disk, or a semiconductormemory. Such a removable recording medium can be provided as so-called“package software”.

[1417] The program may be installed from the above-described removablerecording medium into a computer, as discussed above. Alternatively, theprogram may be wirelessly transferred from a download site to acomputer, or may be transferred to a computer by cable via a network,such as a LAN (Local Area Network) or the Internet. Then, the computerreceives the transferred program, and installs the program into arecording medium, such as a built-in hard disk.

[1418] The various processings described in the specification can beexecuted in chronological order as disclosed in the specification.Alternatively, the processings may be executed in parallel orindividually according to the processing performance of the unit toexecute the processing or according to the necessity. Moreover, in thisspecification, the system is a logical group of a plurality of devices,and the individual devices do not have to be in the same casing.

[1419] Industrial Applicability

[1420] As is seen from the foregoing description, according to thememory access control system, the device management apparatus, thepartition management apparatus, the memory-loaded device, the memoryaccess control method, and the program storage medium, it is possible toimplement a configuration in which various types of access controltickets are issued in response to access to a memory having a pluralityof divided partitions under the control of each device or partitionmanagement entity, and processing based on the rules described in eachticket is executed by the memory-loaded device, thereby implementing aconfiguration in which data in each partition is independently managed.

[1421] According to the memory access control system, the devicemanagement apparatus, the partition management apparatus, thememory-loaded device, the memory access control method, and the programstorage medium, the device is able to execute partition authenticationand device authentication according to a public key designation methodor a common key designation method so as to enable the execution ofsecure data communication between the device and an access unit undervarious environments.

[1422] According to the memory access control system, the devicemanagement apparatus, the partition management apparatus, thememory-loaded device, the memory access control method, and the programstorage medium, the memory of the memory-loaded device includes one ormore partitions for storing data files, which serve as memory areasmanaged by a partition manager, and a device management area managed bya device manager, which serves as a manager of the memory-loaded device.The memory-loaded device then receives from an access unit an accesscontrol ticket managed by the device manager or an access control ticketmanaged by the partition manager as the access control ticket for thememory, and executes processing according to a description in thereceived ticket. Accordingly, the mutual authentication mode and theaccess control ticket verification mode to be conducted can bedesignated, and the processing can be executed according to theindividual modes, thereby enabling the execution of secure datacommunication between the device and the access unit under variousenvironments.

[1423] According to the memory access control system, the devicemanagement apparatus, the partition management apparatus, thememory-loaded device, the memory access control method, and the programstorage medium, a partition registration ticket (PRT), a fileregistration ticket (FRT), a service permission ticket (SPT), and a dataupdate ticket (DUT) are issued under the management of the devicemanager and the partition manager, and the processing in the device isperformed on the condition that authentication and ticket verificationare successfully conducted. It is thus possible to achieve the provisionof services and the data management according to various processingmodes under the management of each service entity.

1. A memory access control system for a memory-loaded device having a memory in which a data file is stored, wherein: the memory of said memory-loaded device includes one or more partitions for storing the data file therein, which serve as memory areas managed by a partition manager, and a device manager management area managed by a device manager, which serves as a manager of said memory-loaded device; and said memory-loaded device receives from an access unit an access control ticket managed by the device manager or an access control ticket managed by the partition manager as an access control ticket for the memory, and performs processing according to a description of the received ticket.
 2. A memory access control system according to claim 1, wherein: the access control ticket includes mutual authentication designation data that designates a mutual authentication mode to be executed between said memory-loaded device and the access unit which outputs the ticket; and said memory-loaded device executes mutual authentication according to the mutual authentication designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that authentication is successfully conducted.
 3. A memory access control system according to claim 1, wherein: the access control ticket includes ticket verification designation data that designates a verification mode of the access control ticket received by said memory-loaded device; and said memory-loaded device executes ticket verification processing according to the ticket verification designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that verification is successfully conducted.
 4. A memory access control system according to claim 1, wherein: the access control ticket includes a category or an identifier of issuing means of the access control ticket; and said memory-loaded device executes processing to check whether the ticket is a ticket issued by authorized issuing means based on the category or the identifier of the issuing means of the access control ticket indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 5. A memory access control system according to claim 1, wherein: the access control ticket includes a category or an identifier of the access unit, which serves as using means of the access control ticket; and said memory-loaded device performs processing to check whether the ticket is a ticket provided by authorized using means based on the category or the identifier of the access unit, which serves as the using means of the access control ticket, indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 6. A memory access control system according to claim 1, wherein: the access control ticket managed by the device manager includes a partition registration ticket (PRT) that allows partition creation processing or partition deletion processing for the memory of said memory-loaded device; and when receiving the partition registration ticket (PRT) from the access unit, said memory-loaded device performs the partition creation processing or the partition deletion processing according to a description recorded in the received partition registration ticket (PRT).
 7. A memory access control system according to claim 6, wherein the partition registration ticket (PRT) is issued from ticket issuing means managed by the device manager to the access unit, which serves as a ticket user managed by the partition manager.
 8. A memory access control system according to claim 1, wherein: the access control ticket managed by the partition manager includes a file registration ticket (FRT) that allows data-file creation processing or data-file deletion processing in a partition which is generated in the memory of said memory-loaded device; and when receiving the file registration ticket (FRT) from the access unit, said memory-loaded device performs the file creation processing or the file deletion processing according to a description recorded in the received file registration ticket (FRT).
 9. A memory access control system according to claim 8, wherein the file registration ticket (FRT) is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 10. A memory access control system according to claim 1, wherein: the access control ticket managed by the partition manager includes a service permission ticket (SPT) that allows access to the data file in a partition in the memory of said memory-loaded device; and when receiving the service permission ticket (SPT) from the access unit, said memory-loaded device accesses the data file according to a description recorded in the received service permission ticket (SPT).
 11. A memory access control system according to claim 10, wherein the service permission ticket (SPT) is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 12. A memory access control system according to claim 1, wherein: the access control ticket managed by the device manager or the partition manager includes a data update ticket (DUT) that allows data stored in the memory of said memory-loaded device to be updated; and when receiving the data update ticket (DUT) from the access unit, said memory-loaded device performs data updating processing according to a description recorded in the received data update ticket (DUT).
 13. A memory access control system according to claim 12, wherein: the data update ticket (DUT) for updating data in the device manager management area managed by the device manager is issued from ticket issuing means managed by the device manager to the access unit, which serves as a ticket user managed by the device manager; and the data update ticket (DUT) for updating the data in the partition managed by the partition manager is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 14. A device management apparatus for executing device management of a memory-loaded device, said memory-loaded device including one or more partitions for storing a data file therein, which serve as memory areas managed by a partition management apparatus, and a device manager management area managed by said device management apparatus, said device management apparatus comprising issuing means for a partition registration ticket (PRT) as a memory access control ticket that allows partition creation processing or partition deletion processing for a memory of said memory-loaded device.
 15. A device management apparatus according to claim 14, wherein said device management apparatus comprises a registration authority structure which manages the issuing of a public key certificate to said memory-loaded device.
 16. A device management apparatus according to claim 14, wherein the partition registration ticket (PRT) includes mutual authentication designation data that designates a mutual authentication mode to be executed between said memory-loaded device and an access unit which outputs the ticket.
 17. A device management apparatus according to claim 14, wherein the partition registration ticket (PRT) includes ticket verification designation data that designates a verification mode of the access control ticket received by said memory-loaded device.
 18. A device management apparatus according to claim 14, wherein the partition registration ticket (PRT) includes a category or an identifier of the issuing means of the access control ticket.
 19. A device management apparatus according to claim 14, wherein the partition registration ticket (PRT) includes a category or an identifier of an access unit, which serves as using means of the access control ticket.
 20. A partition management apparatus for executing partition management of a memory-loaded device, said memory-loaded device including one or more partitions for storing a data file therein, which serve as memory areas managed by said partition management apparatus, and a device manager management area managed by a device management apparatus, said partition management apparatus comprising issuing means for an access control ticket that allows access to a partition generated in a memory of said memory-loaded device.
 21. A partition management apparatus according to claim 20, wherein the access control ticket is a file registration ticket (FRT) that allows data-file creation processing or data-file deletion processing in a partition generated in the memory of said memory-loaded device.
 22. A partition management apparatus according to claim 20, wherein the access control ticket is a service permission ticket (SPT) that allows access to the data file in a partition in the memory of said memory-loaded device.
 23. A partition management apparatus according to claim 20, wherein said partition management apparatus comprises a registration authority structure which manages the issuing of a public key certificate to said memory-loaded device.
 24. A partition management apparatus according to claim 20, wherein the access control ticket includes mutual authentication designation data that designates a mutual authentication mode to be executed between said memory-loaded device and an access unit which outputs the ticket.
 25. A partition management apparatus according to claim 20, wherein the access control ticket includes ticket verification designation data that designates a verification mode of the access control ticket received by said memory-loaded device.
 26. A partition management apparatus according to claim 20, wherein the access control ticket includes a category or an identifier of the issuing means of the access control ticket.
 27. A partition management apparatus according to claim 20, wherein the access control ticket includes a category or an identifier of an access unit, which serves as using means of the access control ticket.
 28. A memory-loaded device having a memory in which data can be stored, wherein: the memory of said memory-loaded device includes one or more partitions, which serve as memory areas managed by a partition manager, and a device manager management area managed by a device manager, which serves as a manager of said memory-loaded device; and said memory-loaded device comprises control means for receiving from an access unit an access control ticket managed by the device manager or an access control ticket managed by the partition manager as an access control ticket for the memory, and for performing processing according to a description of the received ticket.
 29. A memory-loaded device according to claim 28, wherein: the access control ticket includes mutual authentication designation data that designates a mutual authentication mode to be executed between said memory-loaded device and the access unit which outputs the ticket; and said control means executes mutual authentication according to the mutual authentication designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that authentication is successfully conducted.
 30. A membry-loaded device according to claim 28, wherein: the access control ticket includes ticket verification designation data that designates a verification mode of the access control ticket received by said memory-loaded device; and said control means executes ticket verification processing according to the ticket verification designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that verification is successfully conducted.
 31. A memory-loaded device according to claim 28, wherein: the access control ticket includes a category or an identifier of issuing means of the access control ticket; and said control means executes processing to check whether the ticket is a ticket issued by authorized issuing means based on the category or the identifier of the issuing means of the access control ticket indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 32. A memory-loaded device according to claim 28, wherein: the access control ticket includes a category or an identifier of the access unit, which serves as using means of the access control ticket; and said control means performs processing to check whether the ticket is a ticket provided by authorized using means based on the category or the identifier of the access unit, which serves as the using means of the access control ticket, indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 33. A memory access control method for a memory-loaded device having a memory in which a data file is stored, wherein: the memory of said memory-loaded device includes one or more partitions for storing the data file therein, which serve as memory areas managed by a partition manager, and a device manager management area managed by a device manager, which serves as a manager of said memory-loaded device; and said memory-loaded device receives from an access unit an access control ticket managed by the device manager or an access control ticket managed by the partition manager as an access control ticket for the memory, and performs processing according to a description of the received ticket.
 34. A memory access control method according to claim 33, wherein: the access-control ticket includes mutual authentication designation data that designates a mutual authentication mode to be executed between said memory-loaded device and the access unit which outputs the ticket; and said memory-loaded device executes mutual authentication according to the mutual authentication designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that authentication is successfully conducted.
 35. A memory access control method according to claim 33, wherein: the access control ticket includes ticket verification designation data that designates a verification mode of the access control ticket received by said memory-loaded device; and said memory-loaded device executes ticket verification processing according to the ticket verification designation data of the access control ticket, and performs processing according to a description recorded in the received ticket on the condition that verification is successfully conducted.
 36. A memory access control method according to claim 33, wherein: the access control ticket includes a category or an identifier of issuing means of the access control ticket; and said memory-loaded device executes processing to check whether the ticket is a ticket issued by authorized issuing means based on the category or the identifier of the issuing means of the access control ticket indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 37. A memory access control method according to claim 33, wherein: the access control ticket includes a category or an identifier of the access unit, which serves as using means of the access control ticket; and said memory-loaded device performs processing to check whether the ticket is a ticket provided by authorized using means based on the category or the identifier of the access unit, which serves as the using means of the access control ticket, indicated in the access control ticket received from the access unit, and performs processing according to a description recorded in the received ticket on the condition that the checking processing is successfully performed.
 38. A memory access control method according to claim 33, wherein: the access control ticket managed by the device manager includes a partition registration ticket (PRT) that allows partition creation processing or partition deletion processing for the memory of said memory-loaded device; and when receiving the partition registration ticket (PRT) from the access unit, said memory-loaded device performs the partition creation processing or the partition deletion processing according to a description recorded in the received partition registration ticket (PRT).
 39. A memory access control method according to claim 38, wherein the partition registration ticket (PRT) is issued from ticket issuing means managed by the device manager to the access unit, which serves as a ticket user managed by the partition manager.
 40. A memory access control method according to claim 33, wherein: the access control ticket managed by the partition manager includes a file registration ticket (FRT) that allows data-file creation processing or data-file deletion processing in a partition which is generated in the memory of said memory-loaded device; and when receiving the file registration ticket (FRT) from the access unit, said memory-loaded device performs the file creation processing or the file deletion processing according to a description recorded in the received file registration ticket (FRT).
 41. A memory access control method according to claim 40, wherein the file registration ticket (FRT) is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 42. A memory access control method according to claim 33, wherein: the access control ticket managed by the partition manager includes a service permission ticket (SPT) that allows access to the data file in a partition in the memory of said memory-loaded device; and when receiving the service permission ticket (SPT) from the access unit, said memory-loaded device accesses the data file according to a description recorded in the received service permission ticket (SPT).
 43. A memory access control method according to claim 42, wherein the service permission ticket (SPT) is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 44. A memory access control method according to claim 33, wherein: the access control ticket managed by the device manager or the partition manager includes a data update ticket (DUT) that allows data stored in the memory of said memory-loaded device to be updated; and when receiving the data update ticket (DUT) from the access unit, said memory-loaded device performs data updating processing according toga description recorded in the received data update ticket (DUT).
 45. A memory access control method according to claim 33, wherein: the data update ticket (DUT) for updating data in the device manager management area managed by the device manager is issued from ticket issuing means managed by the device manager to the access unit, which serves as a ticket user managed by the device manager; and the data update ticket (DUT) for updating the data in the partition managed by the partition manager is issued from ticket issuing means managed by the partition manager to the access unit, which serves as a ticket user managed by the partition manager.
 46. A program storage medium for providing a computer program for executing memory access control processing on a computer system, said memory access control processing being performed for a memory-loaded device having a memory, said memory including one or more partitions for storing a data file therein, which serve as memory areas managed by a partition manager, and a device manager management area managed by a device manager, which serves as a manager of said memory-loaded device, said computer program comprising: a step of receiving from an access unit an access control ticket managed by the device manager or an access control ticket managed by the partition manager as an access control ticket for the memory; a step of executing mutual authentication with the access unit; a step of executing ticket verification processing according to a description of the received ticket; and a step of performing processing according to the description of the received ticket. 